EMC SOLUTIONS FOR MICROSOFT SQL SERVER WITH EMC VNX SERIES

Transcription

1 EMC SOLUTIONS FOR MICROSOFT SQL SERVER WITH EMC VNX SERIES EMC Solutions Group Abstract This document describes various best practices for deploying Microsoft SQL Server with EMC VNX series storage arrays. It distills the results of extensive testing performed by EMC Strategic Solutions Engineering into actionable best practices that can easily be implemented. December, 2011

2 Copyright 2011 EMC Corporation. All rights reserved. Published December, 2011 EMC believes the information in this publication is accurate 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. VMware, ESX, VMware vcenter, vmotion, and VMware vsphere are registered trademarks or trademarks of VMware, Inc., in the United States and/or other jurisdictions. All other trademarks used herein are the property of their respective owners. Part Number h8307 2

3 Contents Chapter 1 EMC VNX Series for SQL Server Introduction to EMC VNX Series Software suites available Software packs available Improved system performance Efficient storage capacity management Continuous availability Simple management of storage assets Tight integration with virtual environments Chapter 2 Microsoft SQL Server Best Practices SQL Server planning considerations Consider high availability technologies for your SQL Server Consider table and index partitioning Use failover-aware applications Use Microsoft SQL Server Best Practice Analyzer (BPA) to identify potential issues in the database environment Make SQL Server part of an Active Directory domain Enable SQL Server to keep pages in memory Enable Windows fast file initialization Set the database file sizes and autogrow increments appropriately Set Autoshrink to OFF on data and log files Use defaults for processors and memory Set the Windows NT File System (NTFS) allocation unit to 64 KB Do not exceed 80 percent utilization of LUNs Only use hardware that is approved by Microsoft When using MSCS, reboot the passive node occasionally Use quick format for thin pool LUNs on Windows Server Chapter 3 Storage Best Practices Storage best practices overview Plan storage layouts for performance and capacity Use SQLIOSim.exe to validate storage configuration

4 Contents Consider Tempdb performance Size tempdb appropriately For optimal recovery place database and log files on separate spindles Plan database filegroups based on workload File group planning Tempdb User databases Log files Determine whether a pool-based LUN or a RAID group LUN is appropriate for the SQL deployment Plan storage operations for minimal disruption Do not change the default owner of the pool LUN once it is provisioned Balance SQL Server database and log LUNs between storage processors Name the LUNs for quick identification Align Windows disk partitions for best performance Chapter 4 Network Best Practices Network best practices overview Use a dedicated VLAN for cluster heartbeat connectivity Use Powerpath for path failover and high-availability Use the latest verified HBA / NIC driver Plan SQL Server network connectivity for high speed links Set network speed and duplexing Plan for network high availability Chapter 5 Protection Best Practices SQL Server protection best practices overview Use array based replication to offload SQL Server Database mirroring If clustering is used at the principal site, do not use a witness server Plan for high I/O levels at the mirror site for database mirroring Verify that interdatabase consistency is not required before implementing database mirroring Methods to sync SQL Server objects if database mirroring is in use For point-in-time recovery, use database log backups When possible, schedule backups for minimal disruption Do a full backup when you change the database recovery model Increasing LUN Prefetch settings can improve restore performance Using VNX file deduplication and compression feature reduces the storage footprint for SQL backups Chapter 6 Virtualization Best Practices Virtualization best practices overview Align new storage volumes on virtualized servers

5 Contents Use Virtualization Management Servers Make Virtualization Management Servers highly available Be aware of virtual machine time considerations Chapter 7 FAST Best Practices FAST Suite best practices overview Enable FAST cache on highly active SQL Server databases For FAST Cache, allow sufficient time for the cache to warm-up Do not enable FAST Cache for Log LUNs Consider FAST VP for autotiering of data on large SQL databases Appendix A Performance Monitoring and Tuning Performance considerations Windows Performance Monitor RAID group planning RAID level attributes Estimating required performance Calculating disk spindle requirements

6 Figures Figure 1. Microsoft Baseline Configuration Analyzer Figure 2. Select local security policy Figure 3. Perform management tasks Figure 4. Performance comparison Figure 5. Naming LUNs Figure 6. RAID overhead effect for random I/O

7 Tables Table 1. Terminology Table 2. RAID group LUNs vs. pool-based LUNs Table 3. Windows Performance Monitor counters Table 4. RAID level performance characteristics Table 5. I/O types and performance attributes Table 6. Number of spindles required for a series of sample workloads

8 Preface About this document Microsoft SQL Server is a relational database management system (RDBMS) that is widely deployed 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, it is very important to understand these factors and plan accordingly when deploying SQL Server. Storage is an important part in any SQL Server deployment. EMC VNX Series unified storage solutions can help in assessment, design, implementation, and management while lowering the implementation risks and costs of an SQL Server environment. The new EMC VNX Series delivers uncompromising scalability and flexibility while providing market-leading simplicity and efficiency to minimize total cost of ownership. SQL Server deployments can benefit from VNX Series features such as: Improved system performance by extending the cache using Enterprise Flash Drives (EFDs) with EMC FAST Cache. Fully Automated Storage Tiering for Virtual Pools (FAST VP) More efficient storage capacity management with Virtual Provisioning. Block compression and file deduplication. Local and remote data protection suites for protection against local failures, outages, and disasters. This document highlights how the EMC VNX Series unified storage solutions benefit a Microsoft SQL Server database environment. It presents a series of best practices that were discovered and validated during the testing of solutions for using Microsoft SQL Server with EMC VNX Series unified storage. Audience This document is intended for IT administrators, database administrators, data architects, and system engineers who have an interest in implementing Microsoft SQL Server on EMC VNX Series Unified Storage systems. The document is designed for a reader who has a general knowledge of Microsoft SQL Server and EMC Unified storage systems and features. Scope It is important to plan a Microsoft SQL Server deployment for scalability while maintaining acceptable performance, high availability, and an efficient mechanism for disaster recovery. 11

9 Preface This document can be applied in many situations, and is meant to be a collection of recommendations for Microsoft SQL Server storage configuration on EMC VNX. Note The recommendations in this document have been derived mostly from running a TPCC-like workload. A TPCC-like workload is meant to be representative of an OLTP workload. However, no two workloads are the same. The only way to be sure of the effect of a change in an environment is to test the change in that environment. Microsoft SQL Server is an environment, not an application, so the databases it hosts can vary widely. Therefore, it is possible that a recommendation may help in one environment but have a minimal or negative effect in another. Using best practices is not a valid substitute for proper planning, design, and architecture. Terminology Table 1. Terminology Term EFD (Enterprise Flash Drives) Storage pool iscsi (Internet SCSI) LUN (Logical unit number) RAID (Redundant array of inexpensive disks) RAID 1 RAID 10 RAID 5 RAID group Definition A data storage device that uses nonvolatile semiconductor NAND Flash memory to store data. A container that holds a number of disk drives of the same RAID type. A protocol for sending SCSI packets over TCP/IP networks. The identifying numbers of a SCSI or iscsi object that processes SCSI commands. The LUN is the last part of the SCSI address for a SCSI object. The LUN is an ID for the logical unit, but the term is sometimes used to refer to the logical unit itself. A storage method where the data is stored on multiple disk drives to maximize performance and storage capacities, and to provide redundancy and fault tolerance. RAID method that provides data integrity by mirroring (copying) data to another disk. This RAID type provides the greatest assurance of data integrity at the greatest cost in disk space. RAID method that provides data integrity by mirroring data to another disk. This method provides better performance than RAID 1 by striping data across mirrored disk pairs. RAID method where data is written across disks in large stripes. Parity information is stored so that data can be reconstructed if needed. One disk can fail without data loss. Performance is faster for reads but slower for writes. A set of physical disks of a particular RAID type on which one or more LUNs are bound. Each RAID group supports only the RAID type of the first LUN bound on it, and any other LUNs bound on it must have the same RAID type. LUNs are distributed equally across all disks in the RAID group. 12

10 Preface Term SP (Storage processor) System database User database VI client Definition A circuit board with memory modules and control logic that manages the storage-system I/O between the host system Fibre Channel adapter and the disk modules. A database installed as part of Microsoft SQL Server. The system databases include master, model, msdb, and tempdb. A non-system database placed on the server after Microsoft SQL Server installation. Examples include an OLTP application database or data warehouse. The VMware Virtual Infrastructure native client that allows users to administer VMware Virtual Infrastructure functions. 13

11 Chapter 1 EMC VNX Series for SQL Server This chapter presents the following topics: Introduction to EMC VNX Series Software suites available Software packs available Improved system performance Efficient storage capacity management Continuous availability Simple management of storage assets Tight integration with virtual environments

12 EMC VNX Series for SQL Server Introduction to EMC VNX Series VNX series delivers uncompromising scalability and flexibility for the midtier while providing market-leading simplicity and efficiency to minimize total cost of ownership. Customers can benefit from the new VNX features such as: Next-generation unified storage, optimized for virtualized applications Extended cache using Flash drives with FAST Cache and Fully Automated Storage Tiering for Virtual Pools (FAST VP) that can be optimized for the highest system performance and lowest storage cost simultaneously on both block and file Multiprotocol support for file, block, and object with object access through Atmos Virtual Edition (Atmos VE) Simplified management with EMC Unisphere for a single management interface for all NAS, SAN, and replication needs Up to three times improvement in performance with the latest Intel Xeon multicore processor technology, optimized for Flash 6 gigabit/s SAS back end with the latest drive technologies supported: GB and 200 GB Flash, GB, and 600 GB 15k or 10k rpm SAS, and 3.5, 1 TB, 2 TB, and 3 TB 7.2k rpm NL-SAS GB and 200 GB Flash, 300 GB, 600 GB and 900 GB 10k rpm SAS Expanded EMC UltraFlex I/O connectivity Fibre Channel (FC), Internet Small Computer System Interface (iscsi), Common Internet File System (CIFS), Network File System (NFS) including parallel NFS (pnfs), Multi-Path File System (MPFS), and Fibre Channel over Ethernet (FCoE) connectivity for converged networking over Ethernet The VNX series includes five new software suites and three new software packs, making it easier and simpler to attain the maximum overall benefits Software suites available VNX FAST Suite Automatically optimizes for the highest system performance and the lowest storage cost simultaneously (FAST VP is not part of the FAST Suite for the VNX5100). VNX Local Protection Suite Practices safe data protection and repurposing. VNX Remote Protection Suite Protects data against localized failures, outages and disasters. VNX Application Protection Suite Automates application copies and proves compliance. VNX Security and Compliance Suite Keeps data safe from changes, deletions, and malicious activity. Software packs available VNX Total Efficiency Pack Includes all five software suites (not available for the VNX5100). VNX Total Protection Pack Includes local, remote and application protection suites VNX Total Value Pack Includes all three protection software suites and the Security and Compliance Suite (the VNX5100 exclusively supports this package). 16

13 EMC VNX Series for SQL Server Improved system performance The VNX series next-generation storage platform is powered by the quad-core Intel Xeon 5600 series with a 6-Gb/s SAS drive backend. It delivers demonstrable performance improvements over previous generation mid-tier storage systems. The VNX Series is designed to take advantage of the latest innovations in Flash drive technology to maximize performance and efficiency and minimize the cost per gigabyte. Efficient storage capacity management EMC Virtual Provisioning provides pool-based storage provisioning by implementing pool LUNs that can be either thin or thick. Thin LUNs provide on-demand storage that maximizes storage utilization by allocating storage as it is needed and minimizes over-provisioning of storage capacity to reduce the total cost of ownership (TCO). Thick LUNs provide a way to preallocate and dedicate that space for a specific application. Virtual Provisioning also simplifies storage management tasks with the ability to expand pool LUNs (both thin and thick) with a few button clicks. The underlying pools can also be expanded by adding drives nondisruptively when additional storage space is required. This reduces the time and effort required to provision additional storage, and avoids upfront provisioning of storage that may not be needed initially. The VNX series has built-in features to help ensure redundant or inactive data does not consume valuable storage resources. Block compression, intended for relatively inactive LUNs such as backup copies and static data repositories, automatically compresses data. This allows customers to recapture capacity and reduce the data footprint by up to 50 percent. Filelevel de-duplication/compression reduces disk space requirements by up to 50 percent by selectively compressing and de-duplicating inactive files. There is minimal system performance overhead because these features operate as background tasks. Continuous availability The VNX series is architected to provide five 9s availability in mission critical business environments. VNX availability and redundancy features include: Up to 12.8 GB of mirrored write cache, where each storage processor contains both primary cached data for its LUNs, and a secondary copy of the cache for its peer storage processor. Battery backup to allow for an orderly shutdown and cache de-staging to the vault disks to ensure data protection in the event of a power failure. RAID protection levels 0, 1, 1/0, 3, 5 and 6 all of which can co-exist in the same array simultaneously to match different protection requirements. Proactive hot sparing enhances system robustness to deliver maximum reliability and availability. Redundant data paths, power supplies, drive connections, and storage processors- all with non-disruptive field replacement capabilities. Continuous system monitoring, call-home notification, and advanced remote diagnostics. Simple management of storage assets EMC Unisphere makes it easy to manage VNX systems from anywhere with a simple, integrated user interface for distributed storage environments. The Unisphere dashboard is a single screen for at-a-glance management and reporting. Unisphere allows administrators to 17

14 EMC VNX Series for SQL Server gain instant and actionable knowledge about the status of the entire environment. Unisphere provides single sign-on functionality to automatically discover all VNX, EMC CLARiiON, EMC Celerra, and EMC Recoverpoint SE installations in the environment for seamless configuration. Tight integration with virtual environments The VNX Series is the ideal mid-tier system for virtualized SQL database environments. Whether the customer environment is VMware, Microsoft Hyper-V, or Xen-based, VNX is fully certified for all supported protocols to ensure successful deployments of virtualized infrastructures through all phases of implementation. Tight integration of Unisphere with VMware vcenter through VAAI (vstorage APIs for Array Integration) provides both Storage and Virtualization administrators with visibility into the entire environment-end-to-end. Each administrator can use a familiar management interface to view both virtual and physical resources, transparently provision storage, integrate replication, and access and offload all storage functions to the array. EMC Virtual Storage Integrator (VSI) provides a way to monitor and manage EMC VNX systems in virtual environments. EMC VSI for Hyper-V can be installed on Microsoft System Center Virtual Manager and provides administrator the ability to manage both Hyper-V and EMC VNX from one administrative console. Similarly, EMC VSI for VMware vsphere can be installed in VMware vsphere client to manage both VMware and EMC VNX form one administrative console. 18

15 Chapter 2 Microsoft SQL Server Best Practices This chapter presents the following topics: SQL Server planning considerations Consider high availability technologies for your SQL Server Consider table and index partitioning Use failover-aware applications Use Microsoft SQL Server Best Practice Analyzer (BPA) to identify potential issues in the database environment Make SQL Server part of an Active Directory domain Enable SQL Server to keep pages in memory Enable Windows fast file initialization Set the database file sizes and autogrow increments appropriately Set Autoshrink to OFF on data and log files Use defaults for processors and memory Set the Windows NT File System (NTFS) allocation unit to 64 KB Do not exceed 80 percent utilization of LUNs Only use hardware that is approved by Microsoft When using MSCS, reboot the passive node occasionally Use quick format for thin pool LUNs on Windows Server

16 Microsoft SQL Server Best Practices SQL Server planning considerations Good planning prior to deployment is crucial for a successful SQL Server environment. The SQL Server environment should be scalable, highly available, predictable, and manageable during daily operations. The following best practices give important guidelines for planning SQL Server settings, subsequent chapters cover other aspects of the environment. Consider high availability technologies for your SQL Server SQL Server is a mission-critical environment, and requires high-availability. Clustering technologies help protect the SQL Server environment from any network or hardware failures on the server. Microsoft clusters provide a highly available environment to protect against Microsoft SQL Server failures due to hardware, operating systems, device drivers, or applications. If one node in a cluster fails, the service fails over to another node, which provides service in place of the failed node. Getting Started with SQL Server 2008 R2 Failover Clustering available from Microsoft TechNet provides more information about Microsoft Clustering. VMware clustering capabilities also provide high availability for SQL Server virtual machines by monitoring server failure and automatically starting them on another server if necessary. VMware HA clusters provides uniform, cost-effective failover protection against hardware and operating system failures. Availability Guide for Deploying SQL Server on VMware vsphere on the VMware website provides more information about VMware HA. For the highest level of protection against server failure, deploy SQL Server in a cluster environment. Consider table and index partitioning Partitioning breaks up database objects by allowing subsets of data to reside on separate file groups. In a SQL environment, this ability is beneficial in several ways: Improved manageability: Partitioning makes large tables or indexes more manageable. Maintenance operations can be performed on subsets of data, and target only the required data that instead of the whole table. This shortens maintenance windows, improves backup coverage, and reduces backup storage requirements. Reduced costs: Some environments have very large tables that contain historical data. This data may be less valuable than current data, but is still required. Partioning allows the movement of individual sections of the table to lower-cost storage without impacting the whole table Consider FAST VP for autotiering of data on large SQL databases provides more information about additional cost reduction. Improved availability: Partitioning enables database partial availability, which can reduce downtime due to planned and unplanned events. It also enables partial restores to recover a section of a table without impacting the rest of the table. Table and index partitioning improves manageability, reduces costs, and improves availability, but partitioning must be planned and implemented based on the specific environment requirements. Improper planning or implementation may result in negative impacts on the SQL environment. Partitioned Table and Index Strategies Using SQL Server 2008 available on Microsoft TechNet provides more information about partitioning tables and indexes. 20

17 Microsoft SQL Server Best Practices Use failover-aware applications When a Microsoft SQL Server failover occurs with MSCS / Failover clustering, Database Mirroring, or other technologies, all database connections are lost and in-flight transactions are rolled back. To minimize data loss, all applications should be failover-aware, and have reconnect/retry logic. Therefore, in a failover situation, the application will attempt to reconnect, and retry the interrupted transaction once the connection is re-established. Use Microsoft SQL Server Best Practice Analyzer (BPA) to identify potential issues in the database environment After installing the Microsoft SQL Server, run the Microsoft SQL Server Best Practice Analyzer (BPA) tool to identify any potential issues in the database environment. Microsoft SQL Server Best Practice Analyzer (BPA) is diagnostic tool that gathers information from the Microsoft Windows and SQL Server configuration settings. This tool determines the overall health of the SQL Server environment by verifying important settings are configured according to Microsoftrecommended best practices, indicates settings that are different from the recommended practices, reports potential problems, and suggests solutions. Figure 1. Microsoft Baseline Configuration Analyzer 2.0 The Microsoft SQL Server 2008 R2 Best Practices Analyzer page at the Microsoft Download Center provides more information about the SQL Server 2008 R2 Best Practices Analyzer The Microsoft SQL Server 2005 Best Practices Analyzer page at the Microsoft Download Center provides more information about the SQL Server 2005 Best Practice Analyzer. Make SQL Server part of an Active Directory domain Security and account management in Active Directory is more secure, mature, and robust than SQL Server user authentication. Active Directory also allows centralized account administration for the entire environment to reduce administration overhead. Therefore, it is highly recommended to make SQL Server part of Active Directory domain and use Windows authentication mode. Choosing an Authentication Mode available from Microsoft TechNet, provides more information. 21

18 Microsoft SQL Server Best Practices Use SQL Server as a domain controller only in certain unusual circumstances. The SQL Server performance can reduce if SQL Server is a domain controller. Enable SQL Server to keep pages in memory Microsoft SQL Server dynamically allocates and deallocates memory based on the current state of the server to prevent memory pressure and swapping. However, if a process tries to use a substantial amount of memory, SQL Server may not be able to respond quickly enough and the operating system may swap some SQL Server memory to the disk. However, in response to the newly created memory pressure, it is likely the memory that was swapped to the disk contains the memory that SQL Server will soon deallocate to decrease its memory use. It is recommended to prevent SQL Server from swapping memory. This is known as Locking pages in RAM. To lock pages in RAM, select the Lock pages in memory policy on the account that is running the Microsoft SQL Server service. How to: Enable the Lock Pages in Memory Option (Windows) available on the Microsoft website, provides more information about locking pages in memory. Enable Windows fast file initialization When Microsoft SQL Server creates or expands a file, the file must be initialized. Earlier versions of SQL Server had only one option to initialize the space by writing all zeros. This causes a substantial performance impact on the storage system. Microsoft SQL Server 2005 and later versions support fast file initialization, which sets a file end pointer. This operation is nearly instantaneous and minimizes the performance impact. To enable Fast file initialization at the OS level, add the Perform volume maintenance tasks policy to the account that is running the Microsoft SQL Server service. By default, this policy is granted to administrators. To enable fast file initialization on a SQL Server administrator account, complete the following steps: 1. Navigate to Administrative Tools > Local Security Policy. The Local Security Policy page appears. 2. Select User Right Assignment under Local Policies. Figure 2. Select local security policy 22

19 Microsoft SQL Server Best Practices 3. Double-click Perform volume management tasks. The Perform volume management properties dialog box appears. Figure 3. Perform management tasks 4. Click Add User or Group. The Add User window appears. 5. Add the SQL Server administrator account. 6. Restart the SQL services. The Fast file initialization is enabled automatically. Database File Initialization available from Microsoft TechNet provides more information. Set the database file sizes and autogrow increments appropriately Microsoft SQL Server supports the ability to automatically grow both data and log files. However, do not consider this as a method for database sizing. It is a best practice to set the file sizes appropriately and grow them manually during minimal system use, on a planned basis. Use Autogrowth only as a safe option to prevent the files from becoming full and making the database read-only when substantial, unpredicted growth occurs. When database files are expanded, there is an impact on performance. This impact is minimized but not eliminated through fast file initialization (Enable Windows fast file initialization provides more information). Additionally, set the file autogrowth increments considering that the time taken for the growth to occur is short enough to minimize its impact on performance, but large enough to prevent many small allocations that provide file fragmentation. An adequate increase in file size that prevents fragmentation usually impacts the performance of the database. Hence, it is recommended to change file sizes during periods of lower activity on the database. Log files have an additional issue because there are virtual log files within a physical log file, and a virtual log file cannot span file growth increments. Thus, if the log file is set to grow in 1 MB increments, the virtual log file will not exceed 1 MB. This will have a performance impact due to the impact of file expansion. This limit may also make certain transactions impossible to complete. 23

20 Microsoft SQL Server Best Practices Because of these performance implications, it is recommended to use an absolute growth increment (MB or GB) for all the files instead of a percentage growth. Set Autoshrink to OFF on data and log files Autoshrink is a simple mechanism to reduce the size of the database and log file space allocated on the disks. This feature does not consider other aspects of the SQL Server before reducing the size. In many cases, causes significant performance problems. Therefore, it is more beneficial to turn off this feature on the SQL Server. Considerations for the "autogrow" and "autoshrink" settings in SQL Server on the Microsoft Support Knowledgebase provides more information. Use defaults for processors and memory When Microsoft SQL Server is first installed, most of its tunable parameters are set to automatic. It is recommended to retain the default values of these parameters on the server dedicated for SQL Server. Change the default parameters if there are other workloads running on the same server or if there are issues due to the default values. By default, SQL Server runs at a standard priority and ensures that all processors in the system are available for use. Also, SQL Server uses memory based on the requirement until a memory pressure starts. If other processes start consuming memory, SQL Server decreases its memory footprint appropriately to decrease the possibility of a memory swap. Set the Windows NT File System (NTFS) allocation unit to 64 KB When NTFS volume allocates space for SQL Server data files, the smallest chunk of data it can allocate is the allocation unit size. SQL Server stores one NTFS data volume as extent. An extent is eight physically contiguous SQL Server pages, which is 64 KB. To format a new NTFS volume using Disk Administrator for Microsoft SQL Server data files, Microsoft and EMC recommends using a 64 KB block size. SQL Server Best Practices Article available from Microsoft TechNet provides more information. Do not exceed 80 percent utilization of LUNs If NTFS volume needs additional space and that space is not available, NTFS performance may degrade. This situation may spur additional performance degradation by creating excessive disk fragmentation. If the LUN that is servicing Microsoft SQL Server reaches 80 percent utilized drive capacity, perform at least one of following: Remove unnecessary data from the disk. Move some of the data to disks with more space. Add more disk space. This recommendation provides protection against application failure if there is an unexpected growth in the database. Therefore, for best performance and protection against unexpected growth, the utilized drive (NTFS formatted) capacity must not exceed 80 percent. Only use hardware that is approved by Microsoft Using hardware that is on the Windows Hardware Compatibility List (WHCL) decreases the possibility of compatibility problems and increases the level of support that Microsoft will provide if a problem occurs. Note In the case of using Windows on Hypervisors, use only hardware that is validated by Microsoft Server Virtualization Validation Program (SVVP). 24

21 Microsoft SQL Server Best Practices When using MSCS, reboot the passive node occasionally Configuration changes such as disk configuration changes may not be detected by the passive node until a reboot is completed. If the passive node has not detected these changes, then a cluster failover may not succeed. Use quick format for thin pool LUNs on Windows Server 2008 It is important to use quick format option (/Q) while formatting any thin LUN provisioned from EMC VNX to the Windows Server 2008 host. When a non-quick format option is used, every block on the file system is overwritten with zeros. From virtual provisioning perspective, this causes a thin LUN to become fully allocated within its respective thin pool. A quick format allocates only a small amount of space within the pool. However, it is not mandatory to use this option in Windows Even when a format command is executed without the quick format option, the actual allocation does not differ. The non-quick format operation simply adds an additional scan of the disk device in search of media errors. 25

22 Chapter 3 Storage Best Practices This chapter presents the following topics: Storage best practices overview Plan storage layouts for performance and capacity Use SQLIOSim.exe to validate storage configuration Consider Tempdb performance Size tempdb appropriately For optimal recovery place database and log files on separate spindles Plan database filegroups based on workload File group planning Tempdb User databases Log files Determine whether a pool-based LUN or a RAID group LUN is appropriate for the SQL deployment Plan storage operations for minimal disruption Do not change the default owner of the pool LUN once it is provisioned Balance SQL Server database and log LUNs between storage processors Name the LUNs for quick identification Align Windows disk partitions for best performance

23 Storage Best Practices Storage best practices overview A high-performance storage subsystem is crucial for a successful SQL Server deployment. Plan the storage configuration ahead of time to meet the performance and capacity requirement of current and future growth. This chapter details recommendations for the configuration of EMC VNX platforms to use with Microsoft SQL Server. Plan storage layouts for performance and capacity The storage subsystem is one of the most critical components of the SQL Server environment. The storage system must be properly sized for current and future SQL Server workloads to maintain optimum performance. A common error during storage planning for Microsoft SQL Server is designing for storage capacity only. Over the past 20 years, increases in storage capacity have outpaced increases in performance by 1000:1 in disk drives. Performance, not storage capacity is usually the limiting factor for disk drives. Three aspects must be considered, in the priority shown below during storage planning: 1. Size the storage system to meet the performance need 2. Size the storage system to meet the capacity need. 3. Select the appropriate disk and RAID types. Chapter 3 Storage best practices provides information about additional storage planning guidelines. Use SQLIOSim.exe to validate storage configuration All changes to the storage system must be validated before using them with SQL Server to reduce the possibility of errors. This includes changes to the disk array, storage network, or any software on the I/O path. The Microsoft SQLIOSim utility validates the reliability and integrity of the storage subsystem. SQLIOSim simulates the following typical user and system SQL Server activities such as, read, write, checkpoint, backup, sort, and read-ahead operations on the storage system. It is also designed to read pages of written data and validate them with a checkum algorithm. SQLIOSim is not a benchmarking tool for storage planning. It is an IO subsystem validation tool. Microsoft SQLIOSim does not require SQL Server to be installed on the system. Download and install SQLIOSim.exe from Microsoft to validate the storage subsystem for errors prior to installing SQL Server or deploying a database. How to use the SQLIOSim utility to simulate SQL Server activity on a disk subsystem available on Microsoft website provides more information about SQLIOSIM. Note: SQLIOSIM validation will inflate thin storage pools Consider Tempdb performance Tempdb is a global resource system database available to all users connected to a particular instance of the SQL Server. It is used by all databases within the instance to hold all temporary data, such as temporary user objects that are explicitly created, and internal objects created by SQL Server database engine. Tempdb can be very IO intensive. When tempdb and user databases are placed on same set of physical spindles, it can cause disk contention and degrade overall SQL Server performance. 28

24 Storage Best Practices EMC recommends monitoring tempdb and placing it on EMC VNX with appropriate storage sizing. The storage sizing can follow the same principles as designing storage for user databases. Size tempdb appropriately Each time the Microsoft SQL Server service is started, tempdb is dropped and re-created with its initial parameters. If tempdb is initially 128 MB and autogrows to 4 GB during operations, it will be 128 MB again after a restart. Database performance will suffer as tempdb autogrows to 4 GB again. Size tempdb appropriately for the environment to minimize the performance impact: Start with a reasonable size tempdb for the size of databases that are in the same SQL Server instance. For example, a 1 GB tempdb is a reasonable starting point for instance databases with a cumulative total size between 10 GB and 100 GB, but not for 1 TB. A general rule is to set tempdb to be between 1% and 10% of the cumulative total size of all the instance databases Set a valid autogrow increment allows tempdb to grow without heavy fragmentation. Set the autogrow to 10 percent to 20 percent of the initial tempdb size. Do not use a percentage for the growth parameter; calculate the growth in MB to correspond to the percentage. Verify fast file initialization is enabled. Enable Windows fast file initialization and Set the database file sizes and autogrow increments appropriately provide more information. Periodically verify the size and utilization of the tempdb database to observe database growth. Reset the size of the tempdb database to something close to its current size before a shutdown. If the tempdb database from the previous example grew from 1 GB to 5 GB, reset it to start at 5 GB, unless the new size is obviously excessive. For example, if the total size of the user databases was 10 GB, and tempdb was 15 GB, this seems excessive. It is possible for an odd set of scenarios to come together to cause uncharacteristic tempdb growth. If this happens, set the starting size to something smaller than the current size. If tempdb repeatedly grows larger than expected, it is possible the initial size allocated for tempdb is too small. From here, a DBA could diagnose what is causing the excessive growth and then determine if it is valid, or if anything needs tuning. Place tempdb on its own set of spindles. Consider Tempdb performance, Appendix A, and Optimizing tempdb Performance available in the Microsoft MSDN Library, provide more information. For optimal recovery place database and log files on separate spindles Every SQL Server transaction is written to the log files, and then written to the data files. If database data files and log files are on separate physical spindles, it prevents the loss of the log and data files at the same time due to loss of multiple drives. If the data files are lost, restore them from a backup and play back the latest log files from the other set of spindles. This best practice provides an additional recovery mechanism, but testing shows that there is little to no performance benefit on EMC VNX. 29

25 Storage Best Practices Plan database filegroups based on workload SQL Server data files are divided into primary and secondary files. There is one primary file, and one or more optional secondary files. Filegroups help administrators organize and store data files in different locations. Since filegroups can be accessed in parallel, place each filegroup on a different set of spindles to improve SQL Server database performance Filegroups also allow the SQL Server database to be restored in stages by piecemeal restore. File group planning provides more information. In the planning stage, organize SQL Server data files with similar performance and protection needs into a filegroup. Using Files and Filegroups in the Microsoft MSDN Library provides more information. File group planning The number of data files per filegroup (or database, if a single filegroup is used) is dependent on a number of factors. Tempdb In SQL Server 2000, the recommendation for tempdb was to have one file for every CPU core. Therefore, if you have a machine with four CPU sockets and use dual-core CPUs, tempdb should be broken into eight files. This is primarily because of an issue with contention in the GAM and SGAM areas of the files. Contention has been decreased substantially in SQL Server 2005 and later versions, but it is still a possibility because tempdb is used more heavily than in previous versions, because of new features such as row versioning. There is a cost associated in having multiple files per filegroup. This is because SQL Server stripes data across all files in a given filegroup (proportional fill) and accesses all the files simultaneously. If the files are located on LUNs that are on the same RAID group (set of spindles), head movement is induced, which increases latency and decreases throughput. Therefore, the decreased contention of multiple files must be balanced against the increased I/O load. A good midway starting point is to split tempdb into a number of files equal to half the number of CPU cores. Concurrency enhancements for the tempdb database and "Possible thread starvation detected" message may be reported in the SQL Server error log when all worker threads for a particular UMS scheduler are in a wait state in SQL Server in the Microsoft Support Knowledgebase discuss this in more detail. User databases Log files For user databases, a similar decision must be made and similar criteria should be used. However, the contention of user databases is usually much lower. Therefore, the administrator must start with a smaller number of files (for example, one or two) and then increase, if necessary. Increasing the number of files available to a SQL Server database does absolutely nothing for performance. If a database has two log files, Microsoft SQL Server will fill the first log file before beginning to use the second log file. Therefore, the only use of a second log file is to expand a database s logs to a new volume. Determine whether a pool-based LUN or a RAID group LUN is appropriate for the SQL deployment With EMC VNX platforms, there is flexibility to select either virtually provisioned pool LUNs (thick LUNs and thin LUNs) or RAID group (traditional) LUNs to provision storage. Pool-based provisioning provides several functional benefits compared to traditional provisioning. Some of the benefits include Fully Automated Storage Tiering (FAST), efficient 30

26 Storage Best Practices space utilization with thin provisioning, simple and easy management, and compression. A pool LUN can either be thick or thin. It is possible to use a thin LUN to present more storage to an application than to allocate it physically. The physical storage is assigned to the server in a capacity-on-demand fashion from a shared pool. With thick LUNs, all the storage is reserved at the time of creation. Therefore, the host-reported capacity is equal to the actual storage allocated. Table 2 compares RAID group and pool-based LUNs. Table 2. RAID group LUNs vs. pool-based LUNs Feature RAID group LUN Pool-based LUN Maximum drives 16 per RAID group All drives in the array (except vault drives and hot spares) Drive types Single drive type per RAID group Multiple drive types can be mixed in a pool FAST Not supported Supported Virtual Provisioning Not supported Supported with thin LUNs Space utilization Poor Excellent with thin LUNs LUN expansion Possible with MetaLUN, complex Simple, nondisruptive, performed easily Compression Not supported Supported with thin LUNs Performance High Thick LUN - High but less than RAID group LUN Thin LUN - Less compared to Thick LUN Because of the many functional benefits offered by the pool LUNs, it is recommended to use pool-based LUNs, either thick or thin according to the requirements of the environment. However, if milliseconds of performance is critical in the environment and the performance requirements outweigh the functional benefits, use the RAID group LUNs because they provide the best performance. EMC CLARiiON Virtual Provisioning Applied Technology white paper available on the EMC Online Support website, provide more information on pool LUNs and RAID group LUNs. Figure 4 shows the performance difference between the thick pool LUNs, thin pool LUNs, compressed thin LUNs, and RAID group LUNs. These results are from the validated solution for Microsoft SQL Server 2008 using EMC VNX5700 and Windows Server The workload used in these tests is SQL OLTP (TPC-C like). 31

27 Storage Best Practices Figure 4. Performance comparison In the tested environment, the RAID group LUNs performed nearly 16 percent better than thick pool LUNs. Thin pool LUNs showed minor decrease in performance when compared to thick LUNs, while compressed LUNs showed a marginal 4.5 percent decline. Plan storage operations for minimal disruption Some operations on the storage array can consume resources and may cause an impact on the production system if executed during a heavy production load. For this reason, schedule storage-based operations that may consume resources during non-peak hours to minimize the potential for such occurrences Do not change the default owner of the pool LUN once it is provisioned Changing a pool LUN s ownership may adversely affect the performance because even after changing the ownership, a pool LUN s private information remains under the control of the original owning storage processor (SP). This results in both SPs being used to handle the I/Os. Involving both SPs increases the time and resource used to complete an I/O of a particular LUN. If a host path failure results in some LUNs trespassing in a shared pool, repair the failure quickly and return the ownership of those trespassed LUNs to their default SP. The ALUA feature of CLARiiON will eventually link both the trespassed pool LUNs and their private information under the sole control of the new owning SP. However, response time will be higher until this occurs. To change the SP ownership after the LUN is created, use LUN migration to migrate the LUN to a new LUN with the required SP. The EMC CLARiiON Asymmetric Active/Active feature white paper available on the EMC Online Support website provides more details on the ALUA feature. 32

28 Storage Best Practices Balance SQL Server database and log LUNs between storage processors When one EMC VNX storage processor is overloaded, performance of the LUNs owned by that SP is dregaded due to resource contention. To provide optimum performance, LUNs that contain SQL Server database and log data must be balanced between the SPs so that a single SP is not overloaded. This provides optimum performance to the SQL Server storage environment. Allocating LUN ownership must be based on LUN resource utilization rather than the number of LUNs. For more details on how to change LUN ownership, refer to Do not change the default owner of the pool LUN once it is provisioned. Name the LUNs for quick identification Naming the LUNs enables quick identification as shown in the following example. This is more useful when several LUNs are created in the storage array for different applications. Figure 5. Naming LUNs Proper naming convention enables users to quickly identify and fix any potential errors. 33