ENHANCING THE PERFORMANCE AND PROTECTION OF MICROSOFT SQL SERVER 2012

Transcription

1 White Paper ENHANCING THE PERFORMANCE AND PROTECTION OF MICROSOFT SQL SERVER 2012 EMC Next-Generation VNX, EMC FAST Suite, EMC AppSync, EMC PowerPath/VE, Boosting OLTP performance Optimizing storage efficiency Enabling fast recovery EMC Solutions Abstract This white paper demonstrates how storage performance for Microsoft SQL Server can be significantly improved at low capital and operational cost on EMC next-generation VNX series storage arrays. It also describes how EMC AppSync with VNX Snapshots provides enterprise-grade protection for critical SQL Server databases with negligible performance impact to the busy OLTP workloads and enables rapid, orchestrated recovery of the databases. December 2013

2 Copyright 2013 EMC Corporation. All Rights Reserved. Published December 2013 EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. The information in this publication is provided as is. EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. EMC 2, 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. Part Number H

3 Table of contents Executive summary... 6 Business case... 6 Solution overview... 7 Key results... 7 Introduction... 9 Purpose... 9 Scope... 9 Audience... 9 Terminology... 9 Technology overview Overview EMC next-generation VNX Multicore architecture Flash-optimized hybrid array Active/active array service processors Unisphere Management Suite EMC FAST Suite EMC FAST VP EMC FAST Cache EMC AppSync EMC PowerPath/VE Solution architecture and configuration Overview Solution architecture Hardware resources Software resources Workload profile Storage considerations Balancing storage processors Balancing cores on storage processor Balancing back-end ports SP cache settings Cache size configuration Flushing SP cache page size

4 Thin provisioning Hot spare settings Balancing data through FAST VP Balancing data through FAST Cache Storage design Disk layout Storage pool configuration FAST VP design FAST Cache design Data protection VMware configuration Virtual machine configuration Memory settings Application design and configuration SQL Server 2012 design and configuration Design and requirements LUN configuration AppSync design and configuration Adding storage Adding VMware vcenter Server Adding host Discovering SQL Server instances and databases Creating service plan Subscribing a database to the plan Validation Overview Test objectives Notes Testing methodology Test scenarios Performance test procedures Test results Throughput testing Throughput in IOPS and TPS Host latency Physical disk utilization Storage processor utilization Protection testing Performance testing with snapshots Restore testing

5 Conclusion Summary Findings References White papers Product documentation Other resources Appendix: Hot spare policy

6 Executive summary Business case 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, fewer resources, and less infrastructure. As the foundation of the cloud-ready information platform, Microsoft SQL Server 2012 provides high availability, breakthrough insight, credible and consistent data, and a productive development experience to customers. It can also quickly build solutions and extend data across on-premises and public clouds backed by mission-critical confidence. EMC provides a set of unique and powerful storage and data management features optimized for SQL Server. Designed to work with the EMC next-generation VNX series of storage platforms, these advanced features dramatically improve efficiency by simplifying and automating many storage tasks. Enabled with EMC MCx software, the new VNX storage arrays are designed to address the high-performance, low-latency requirements of virtualized applications and database systems such as SQL Server, which is the most common use case for midrange solutions. MCx software takes full advantage of the latest Intel multicore processing technology to optimize flash by distributing all VNX data services across all cores. This is a new approach for midrange arrays enabling the next-generation VNX to deliver the performance of the earlier generation at only one-third of the price. Data protection is among the most important aspects of managing SQL Server environments. Database administrators (DBAs) and storage administrators need a rapid, simple, and lower-cost process for protecting mission-critical SQL Server instances. Given those needs, more businesses are looking for advanced data protection technologies for SQL Server 2012 environments. EMC AppSync offers simple, service-level agreement (SLA)-driven, self-service protection for mission-critical SQL Server databases and VMware datastores on block and file storage on VNX series systems. This solution provides a detailed SQL Server storage, compute, and protection design that addresses all the previously described challenges by using the following software suites: EMC Fully Automated Storage Tiering (FAST ) Suite Automatic storage optimization for the highest OLTP performance and the lowest storage cost simultaneously EMC Application Protection Suite SQL Server integrated data protection and repurposing 6

7 Solution overview This solution demonstrates EMC s latest supporting infrastructure for SQL Server 2012 with Windows Server 2012 and VMware ESXi on an efficient, scalable VNX storage platform using block connectivity. The solution shows simulated online transaction processing (OLTP) workloads with excellent storage performance characteristics, optimized with the latest EMC FAST Cache, EMC FAST for Virtual Pools (FAST VP), and Snapshot technologies within the VNX array. This solution demonstrates the ability of a modestly configured EMC VNX5800, as an example of a storage array within the next-generation VNX series, to support multiple OLTP workloads exceeding 50,000 inputs/outputs per second (IOPS) at low cost. The solution combines a pool of serial-attached SCSI (SAS) drives and a small number of flash drives into one powerful storage pool capable of reacting to dynamic workloads. It also shows the benefits of adding additional flash drives to the environment and enabling FAST Cache to further boost performance. This solution also demonstrates the enhanced snapshot protection for SQL Server OLTP databases provided by AppSync and VNX Snapshots technology. It demonstrates that VNX Snapshots has minimal performance impact on the running SQL Server OLTP workload and provides for rapid recovery. In addition, the solution illustrates the functionality of AppSync data protection software, including its ease of deployment and self-service capabilities. Key results The key results of this solution are: The next-generation VNX series of storage arrays can easily service SQL Server OLTP workloads, even with significant performance demands, by maximizing the efficiency and effectiveness of EMC flash technology. In this solution, a midrange VNX series system, VNX5800, was used. The combination of FAST VP and FAST Cache allows VNX storage arrays to maxmize storage efficiency and service increased I/O. This solution shows a four times improvement in the ability to service I/O from the baseline of 13,148 IOPS to 52,303 IOPS, and the latency dropped from more than 20 ms to less than 8 ms with FAST Suite enabled. Thin LUNs provide good performance within a FAST VP enabled storage pool. AppSync with VNX Snapshots provides simple, fast, and self-service application protection with minimal impact to the running SQL Server OLTP workload. AppSync provides enabled, rapid data recovery. The AppSync server restores a 1 TB SQL Server database LUN in 8 minutes 37 seconds. Figure 1 shows the key findings of this solution. 7

8 Figure 1. Key findings of this solution Table 1 lists the time taken to restore the VNX Snapshots of a 1 TB SQL Server OLTP database LUN. Table 1. Restore testing results Item Recovery time Data changes (GB) Snap 1 8 min 37 sec 55 Snap 2 6 min 27 sec 40 Snap 3 6 min 23 sec 27 Snap 4 6 min 48 sec

9 Introduction Purpose This white paper showcases the ability of the VNX5800 storage array to easily support more than 50,000 Microsoft SQL Server OLTP IOPS at low cost by using a combination of SAS and a small number of flash drives. FAST VP and FAST Cache technologies provide significant performance improvement for Microsoft SQL Server in an automated, nondisruptive fashion. This white paper also describes the ease of configuration of AppSync server and VNX Snapshots and their functionality to provide protection for Microsoft SQL Server instances. The solution described in this white paper validates the minimal performance impact of VNX Snapshots on the running SQL Server OLTP workload and measures the recovery time from the snapshots. Scope The scope of this solution is to: Demonstrate the ability of the VNX5800 to easily service over 50,000 IOPS for multiple SQL Server instances at low cost Demonstrate the good performance of thin LUNs within a FAST VP enabled storage pool Demonstrate the function and configuration of AppSync with VNX Snapshots Measure the performance impact of VNX Snapshots on a running SQL Server OLTP workload Measure the recovery time from the snapshots for the SQL Server application Audience Terminology This white paper is intended for EMC employees, partners, and customers, including IT planners, storage architects, application administrators, and EMC field personnel who are tasked with deploying such a solution in a customer environment. It is assumed that the reader is familiar with the various components of the solution. Table 2 defines terminology used in this white paper. Table 2. Terminology Term IOPS iscsi LUN Definition Input/output per second; a measure of disk performance in terms of I/O command-processing throughput per second Internet small computer system interface; an IP-based storage networking standard for linking data storage facilities Logical unit number; an identifier used to describe and identify logical storage objects of a storage subsystem 9

10 Term MCx Memory balloon OLTP RPO RTO Skew SLIC TLB TPS VDM VMDK Working set Definition EMC multicore optimized architecture that fully utilizes all available cores and includes three primary components: Multicore Cache, Multicore FAST Cache, and Multicore RAID A memory reclamation technique in VMware Online transaction processing (such as a workload from a trading or banking application) Recovery point objective; the maximum tolerable period in which data might be lost from an IT service due to a major incident Recovery time objective; the period of time within which systems, applications, or functions must be recovered after an outage; the amount of downtime that a business can endure A small percentage of overall capacity responsible for most I/O activities Small I/O cards, also known as UltraFlex I/O modules Transaction look-aside buffer; a cache that memory management hardware uses to improve virtual address translation speed Transactions per second Virtual Data Mover Virtual Machine Disk The percentage of the total utilized capacity that is responsible for most of the I/O activity 10

11 Technology overview Overview EMC next-generation VNX The following components are used in this solution: EMC next-generation VNX EMC FAST Suite EMC AppSync EMC PowerPath /VE 5.1 The EMC VNX series of storage systems is optimized for virtual applications and delivers innovation and enterprise capabilities for file, block, and object storage. The next-generation VNX series arrays include many features and enhancements built upon the first generation s success including: More capacity with multicore optimization with MCx Greater efficiency with a flash-optimized hybrid array Better protection by increasing application availability with active/active Easier administration and deployment by increasing productivity with EMC Unisphere Management Suite The next-generation VNX is architected to deliver greater efficiency, performance, and scale than ever before. Multicore architecture The VNX architecture unleashes the power of MCx technology, as shown in Figure 2. The system is optimized to distribute all services such as RAID, I/O, FAST Cache, data, and management evenly across the cores in a uniform manner, delivering up to four times more performance than that of its predecessor. Figure 2. MCx improves resource use across CPU cores This multicore design means that VNX delivers FLASH 1 st at scale, with more capacity, using the latest Intel multicore technology, along with the software to take advantage of the increased power. In addition to providing improved block performance, the VNX series with MCx has improved the file performance for transactional 11

12 applications. It delivers three times the IOPs with less read and write latency to critical business applications in virtualization environments. Flash-optimized hybrid array The next-generation VNX is a flash-optimized hybrid array that provides automated tiering to deliver the utmost performance to the data that requires it the most while intelligently moving less frequently accessed data to lower-cost disks. In this hybrid approach, a tiny percentage of flash drives in the overall system can provide a high percentage of the overall IOPS. The flash-optimized VNX takes full advantage of the low latency of flash and delivers progressively lower cost with performance at scale. The FAST Cache and FAST VP tiers both block and file data across heterogeneous drives and boost the most active data to cache, ensuring that customers never have to make concessions for cost or performance. FAST Cache dynamically absorbs unpredicted spikes in system workloads. As that data ages and becomes less active over time, FAST VP automatically tiers the data from high-performance to high-capacity drives based on customer-defined policies. This functionality has been enhanced with four times better granularity and with FAST VP solid-state drives (SSDs) based on enterprise multilevel cell (MLC) technology to lower the cost per gigabyte. Active/active array service processors The VNX architecture provides active/active array service processors. As shown in Figure 3, active/active processors eliminate the application time-outs during path failover because both paths are actively serving I/O. Figure 3. Active/active processors increase performance, resiliency, and efficiency Load balancing is also improved and applications can achieve up to two times improvement in performance. Active/active for block is ideal for applications that require the highest levels of availability and performance but do not require tiering or efficiency services like compression, deduplication, or snapshot. With this VNX release, EMC customers can use Virtual Data Movers (VDMs) and VNX Replicator to perform automated and high-speed file system migrations between 12

13 systems. This process migrates all snaps and settings automatically and allows the clients to continue operation during the migration. Unisphere Management Suite The next-generation VNX is delivered with Unisphere Management Suite, shown in Figure 4. Unisphere s easy-to-use interface provides a task-based integrated management experience for VNX to manage, report, and monitor the storage. It offers greater insight into the utilization and workload patterns, enabling you to diagnose issues, and forecast and plan for future capacity needs. Figure 4. Unisphere Management Suite EMC FAST Suite EMC FAST Suite is an advanced software feature providing greater flexibility to manage the increased performance and capacity requirements of the SQL Server environment. FAST Suite makes use of SSDs, SAS, and near-line SAS (NL-SAS) storage configuration to balance performance and storage needs. FAST Suite includes FAST VP and FAST Cache. EMC FAST VP FAST VP allows data to be automatically tiered in pools made up of more than one drive type. The separate tiers are each provisioned with a different type of drive. FAST VP algorithmically promotes and demotes user data between the tiers based on how frequently the data is accessed. More frequently accessed data is moved to higher performance tiers. Infrequently accessed data is moved to modestly performing high-capacity tiers as needed. Over time, the most frequently accessed data resides on the fastest storage devices, and infrequently accessed data resides on economical and modestly performing bulk storage. EMC FAST Cache The VNX series supports an optional performance-enhancing feature called FAST Cache. FAST Cache increases the storage system cache by extending the functionality of DRAM cache, mapping frequently accessed data to SSDs. If the user application frequently accesses a particular chunk of data (64 KB), that chunk is automatically promoted into the FAST Cache by being copied from HDDs to flash drives. Subsequent access to the same chunk is serviced at flash-drive response time, boosting the performance of the storage system. 13

14 FAST Cache is most suitable for I/O-intensive, random workloads with small working sets. A typical OLTP database with this kind of profile can greatly benefit from FAST Cache to improve performance and response time. EMC AppSync EMC AppSync provides simple, self-service application protection with tiered protection options and proven recoverability. AppSync protects an application by creating copies of application data. Subscribing a Microsoft SQL Server 2012 database (for example) to a service plan indicates to AppSync that you want to protect that database. When the service plan runs, one or more copies are created. The service plan can also mount the copy, validate it, and run user-created scripts. A service plan comprises multiple phases, including create copy, mount copy, validate copy, unmount copy, and phases that run optional user-provided scripts. AppSync includes several application-specific plans (for Exchange, SQL Server, and so on) that work without modification. With the Subscribe to Plan and Run command, you apply the settings of a service plan to your data and protect it immediately. When you subscribe an object to a service plan, it joins any other objects that are already part of the plan. All objects in the service plan are subject to the workflows and settings defined in the service plan. AppSync can generate reports that tell you whether your data is protected, recoverable, and compliant with SLAs. The reports included with AppSync work without modification. Alerts and reports can be easily viewed at the top level of the AppSync dashboard. Alerts can be sent by , and reports can be exported to comma-separated values (CSV) files. Figure 5 shows that the plan was executed successfully. Figure 5. Service Plan Completion Report Figure 6 depicts the architecture of using AppSync to protect a Microsoft SQL Server 2012 standalone instance. 14

15 Figure 6. AppSync for SQL Server 2012 AppSync components include the AppSync server software, host plug-in software, user interface, and REST interface. AppSync server software The AppSync server software resides on a supported Windows system. It controls the service plans and stores data about each copy it creates. The repository is stored in a SQL Server 2012 database on the AppSync server. Host plug-in AppSync installs lightweight plug-in software on the production and mount hosts. AppSync pushes the plug-in software from the AppSync server to the host when you add the host as a resource. In an environment that prevents the AppSync server from accessing a host, you can install the plug-in manually. AppSync user interface The AppSync console is web-based and supports Chrome, Internet Explorer, and Firefox browsers. Flash and Java Runtime Environment are required. The AppSync Support Matrix on EMC Online Support is the authoritative source of information on supported software and platforms. REST interface AppSync has a REST interface that allows application programmers to access information controlled by AppSync. The API is described in the AppSync REST API Reference, which is available on EMC Online Support. 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 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. 15

16 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 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 vmotion and VMware vsphere Storage vmotion features of vsphere 5.1 enable the seamless migration of virtual machines and stored files from one vsphere server to another, with minimal or no performance impact. Coupled with Distributed Resource Scheduler (DRS) and Storage DRS, virtual machines have access to the appropriate resources at any point in time through load balancing of compute and storage resources. 16

17 Solution architecture and configuration Overview Solution architecture The environment in this solution consists of two SQL Server 2012 instances. Each instance runs on a Windows Server 2012 virtual machine that is hosted on an ESXi 5.1 two-node cluster. Storage is provided on the VNX5800 array. For cost-effective purposes, we connect the ESXi hosts to the storage through iscsi connections. The solution design includes the following physical components: Two VMware ESXi hosts, each hosting a virtual machine with one SQL Server instance EMC VNX5800 SAN storage Figure 7 displays the physical architecture of the solution. Figure 7. Solution architecture 17

18 Hardware resources Table 3 details the hardware resources used in this solution. Table 3. Hardware resources Equipment Quantity Configuration EMC next-generation VNX x 10K 900 GB SAS 20 x 200 GB SAS Flash 120 x 7.2K 3 TB NL SAS FLARE OE 33 SP2 FAST enabler licensed IP switches 2 60-port, 10 Gb Fibre Channel over Ethernet (FCoE)-capable switches Servers 2 2-U servers, Intel Xeon E GHz: Two sockets, 10 cores per socket 160 GB memory 2 x dual port 10 Gb iscsi converged network adapter (CNA) cards Software resources Table 4 details the software resources used in this solution. Table 4. Software resources Resource Quantity Version Purpose EMC VNX5800 block operating environment VNX operating environment EMC PowerPath/VE Advanced multipathing for host iscsi connections Windows Server Enterprise Edition, x64 Server operating system VMware ESXi update 1 Hypervisor Microsoft SQL Server Enterprise Edition Service Pack 1 Database servers for OLTP workload EMC AppSync Data protection 18

19 Workload profile Table 5 details the SQL Server workload profile used in validating this solution. To avoid resource contention among the databases, we separated the SQL Server OLTP databases on two SQL Server instances, each one hosting two databases. Table 5. Microsoft SQL Server 2012 workload profile Profile characteristic SQL Server instance 01 SQL Server instance 02 Workload type Quantity/Type/Size 100,000 users/1 TB 25,000 users/250 GB 50,000 users/500 GB 5,000 users/50 GB OLTP-like (90:10 read/write ratio) Storage considerations This section describes storage considerations for this solution. Balancing storage processors In this solution, two SQL Server OLTP instances are on separate ESXi hosts that share the same front-end ports on the VNX. The IP switches are redundant, with the second switch continuing to handle all the network traffic in the event of a hardware failure on the primary IP switch. Figure 8 shows the network diagram between the front-end ports and the hosts for the SQL Server applications. Figure 8. Network diagram In earlier VNX and EMC CLARiiON CX series platforms, each LUN has a single owning storage processor (SP). The host SCSI interface is active/active, with the array servicing I/O from both the owner and the non-owner. However, the non-owner has substantially worse performance. I/O from the non-owning SP is redirected to the owning SP, using the inter-sp CLARiiON Messaging Interface (CMI) interconnect. The MCx infrastructure has no concept of owner, with no per LUN asymmetry of performance between ports on different SPs. Pool-based LUNs continue to have the concept of ownership, and incur the asymmetry of performance between the LUN 19

20 owner and non-owner; therefore, the owning SP would be reported as active/optimized, and the non-owning SP as active/non-optimized to the multipath software on the host. An EMC FLARE LUN has no concept of ownership, and MCx reports all paths as active/optimized to the multipath software on the host. In this solution, we configured pool LUNs for the SQL Server applications, which follows the EMC best practice of balancing SP utilization to fully utilize the storage processing power by distributing the load and binding the LUN owner evenly to both SPs. Because the active/optimized paths are evenly distributed, the loads are pushed to the SPs evenly. Table 9 on page 31 lists the owner for each LUN. Balancing cores on storage processor In MCx, every front-end and back-end port has preferred and alternating core assignments. MCx keeps front-end host requests serviced on the same core on which they originated, avoiding the adverse performance impact of swapping context between CPU cores. On the back end, every core has access to every drive, and servicing requests to the drives do not require swapping between CPU cores. MCx uses the CPU processing more effectively and enables scaling performance. As port usage grows and I/O load increases, MCx automatically distributes processing to all available cores within the same socket. Each slot is affined to a specified socket, with the front-end ports of the SLIC in the slot are affined to the cores within the socket in a round robin manner. The EMC best practice is to distribute the SLICs across the sockets by selecting the slots, so that the user workloads can evenly utilize the sockets on the SP. Balancing back-end ports The next-generation VNX back-end ports are 6 Gb/s SAS. Table 6 shows the maximum back-end SAS ports supported in each next-generation VNX model. Table 6. Maximum back-end SAS ports per SP Model Maximum back-end SAS ports per SP VNX VNX VNX VNX VNX VNX The next-generation VNX can support more back-end ports than the earlier VNX. VNX5800, for example, supports up to six ports, whereas VNX5700 supports a maximum of four ports. 20

21 To achieve better performance, you can balance back-end ports through both physical and logical layers as follows: 1. Spread each drive type across all available buses by physically distributing or relocating drives between DPEs and DAEs. MCx has two features, Drive Mobility and DAE Re-cabling, which allow for physically moving drives and entire DAEs inside the same frame from their existing locations to other slots or buses. In earlier VNX and CX platforms, FLARE identifies drives by their physical address, for example: Bus 0 Enclosure 1 Disk 5. When a drive is moved to another slot, FLARE does not recognize the movement; consequently, any data that is on the disk is lost. In MCx, the drives are identified by their serial number instead of physical address, allowing online drive movement. RAID group data continues to be available after the drive is pulled out. When a drive becomes unavailable, MCx starts a 5-minute counter, and drive sparing is invoked after the 5-minute interval passes. However, some users like to rearrange the entire storage pool, which may be safer and faster to do when the array is shut down; DAE Recabling satisfies this requirement. Users can simply shut down the array, cable DAEs as needed, and power the array back up. Upon power up, the array will easily locate the drives, by surveying their serial numbers, validate all RAID group members, and then continue operations. 2. Create LUNs to distribute their I/O evenly across the back-end ports. SP cache settings Cache size configuration In earlier VNX and CX platforms, FLARE divides the SP cache into three regions: read cache, write cache, and peer SP-mirror write cache. If the needed data resides in the cache, host read requests can be satisfied from either read or write cache. Read misses result in data being loaded into the read cache. Host write requests are satisfied from write cache and then mirrored to the peer SP cache. Unlike with FLARE cache, Multicore Cache does not split the memory between read and write functions. The cache is shared for writes and reads, and the dirty cache page is copied to disk rather than being discarded. This improves the performance by page rehits including re-read and overwrite. Therefore, with earlier VNX and CX platforms, you had to consider adjusting the read/write cache ratio according to the workload characteristic. On next-generation VNX platforms, this configuration is no longer necessary. Flushing In earlier VNX and CX platforms, FLARE has a condition called forced flushing. It occurs when the percent count of dirty cache pages crosses over the high watermark and reaches 100 percent. Then the cache starts forcefully flushing unsaved data to disk, suspending all host I/O. Forced flushing continues until the percent count of dirty pages recedes below the low watermark. It affects the entire array and all workloads served by the array, and significantly increases the host response time until the number of dirty cache pages falls below the low watermark. 21

22 Multicore Cache changes the cache-cleaning model, eliminating the pre-set dirty cache page watermarks. Multicore Cache keeps track of dirty cache pages and the incoming write requests to the underlying RAID group, and evaluates the difference between the rate of incoming host writes and the rate of RAID group page flushes, dynamically reacting to workload changes. Multicore Cache avoids overwhelming the cache by write throttling and satisfying the temporary short bursts. With earlier VNX and CX platforms, you had to consider adjusting the high/low watermark based on the workload changes and impact from forced flushing. On nextgeneration VNX platforms, this configuration is no longer necessary. SP cache page size The SP cache page size setting, which determines the minimum amount of SP memory to service a single I/O operation, has been removed from Multicore Cache. With earlier VNX and CX platforms, users can adjust the SP cache page size according to the predominant I/O size: Maintain the default 8 KB for the majority of workloads Increase the page size to the maximum 16 KB for predominant large-block I/O size Match the cache page size to the predominant I/O size for predominant small-block I/O sizes like 2 KB or 4 KB In Multicore Cache, the page size setting has been removed. Multicore Cache has two separate page sizes: physical page and logical page. The physical page size is 8 KB, while one logical page contains from one to eight physical pages. Multicore Cache uses logical pages to handle I/O operations. This solution uses the default SP cache setting with write cache enabled on the array. Thin provisioning Thin LUNs maximize ease of use and capacity utilization, and take advantage of enabling data services such as VNX Snapshots, deduplication, and compression. Thin LUNs can provide moderate performance in most environments, typically having lower performance than thick LUNs because of the indirect addressing. Thin LUN metadata workload overhead adds cost, however. If thin LUN metadata cannot be satisfied by SP memory, you must add a flash tier to which thin LUN metadata is promoted to improve performance. Virtual Provisioning for the New VNX Series provides more information. In this solution, we use thin LUNs to store SQL Server data to improve the storage efficiency and take advantage of VNX Snapshots technology. Based on thin provisioning, we can easily achieve 50,000 IOPS and more on the next-generation VNX by using flash technologies. Hot spare settings In earlier VNX and CX platforms, to protect the data disk, you must create the RAID groups as hot spares by selecting the specific disks. For each drive type, you must create separate hot spares so that flash drives are spares for flash drives, SAS drives are spares for SAS drives, and NL-SAS drives are spares for NL-SAS drives. The best 22

23 practice is to configure one hot spare disk for every 30 disks, and the hot spare capacity should be equal to or larger than the productive drives. Multicore RAID changes the way hot sparing functions to that you no longer select specific drives as hot spares. You enable a hot spare policy on the array, and the array automatically selects an unconfigured disk as a spare as needed. In this solution, we enabled the default hot spare policy on the array, which uses one drive per 30 drives for each drive type. Balancing data through FAST VP In next-generation VNX, FAST VP granularity is smaller than with earlier VNX platforms 256 MB per slice compared to 1 GB per slice in earlier VNX and CX platforms. That allows FAST VP to move more hot data to the highest tier and fully use the flash drives to boost performance more efficiently. FAST VP and FAST Cache are suitable for workloads with high skew and small working sets. OLTP environments commonly yield working sets of 20 percent or less of their total capacity. In this solution, the typical workload we used during the verification test had the skew of 83/17, meaning that 83 percent of I/O operations accessed 17 percent of the total data capacity. In this solution, to balance the best performance and total cost of ownership (TCO), we expanded the SAS-only pool storing SQL Server data with two flash drives and enabled FAST VP on the pool. With FAST VP enabled, the metadata of thin LUNs can be promoted to the flash tier, which improves overall performance. Balancing data through FAST Cache In earlier VNX and CX platforms, FAST Cache is located above the SP cache. In MCx, the Multicore FAST Cache is below the Multicore Cache. MCx is quicker to acknowledge a host read/write than was possible with earlier platforms because Multicore Cache handles host I/O before searching the FAST Cache memory map. From a performance point of view, FAST Cache provides an immediate performance benefit to bursty data such as SQL Server checkpoint running. FAST Cache and FAST VP features can be used together to yield high performance and TCO from the storage system. From a TCO perspective, FAST Cache can service active data with fewer flash drives, while FAST VP optimizes disk utilization and efficiency for SAS and NL-SAS drives. In this solution, we configured the FAST Cache with six flash drives in three pairs. Following the best practice to spread the flash drives across the buses, we placed two flash drives on Bus 0 and another four flash drives on Bus 2. Storage design This section shows the disk layout and storage configurations used in VNX5800. Design considerations involve many aspects. Always check the latest best practice and design considerations before building your solution. 23

24 Disk layout Figure 9 shows the disk layout we designed in this solution with FAST VP and FAST Cache enabled. Figure 9. Disk layout We spread the drives in the SQL OLTP data pool, SQL Server tempdb and log pool, and FAST Cache evenly across two buses to balance the back-end ports. Note: We enabled the default hot spare policy on the array, allowing for one hot spare drive per 30 drives for all three drive types. And we had enough unused disks available on different buses to be used by Multicore RAID for hot spares. 24

25 Storage pool configuration Table 7 details the VNX storage-pool configuration for the solution. We separated the storage pools according to the I/O pattern and SQL Server best practices. Table 7. EMC VNX5800 storage pool configuration Pool RAID type Disk configuration Purpose SQL Server OLTP data pool RAID5 (4+1) 60 x 900 GB 10K SAS Performance tier for SQL Server OLTP database RAID10 (4+4) 2 x 200 GB MLC flash Extreme performance tier for SQL Server OLTP database SQL Server tempdb and log pool RAID10 (4+4) 8 x 900 GB 10K SAS SQL Server tempdb database and logs for SQL Server OLTP database Virtual machines OS pool RAID10 (4+4) 4 x 3 TB NL-SAS Virtual machine OS pool including SQL Server virtual machine, AppSync server, and Domain Controller; also for SQL Server system databases On the VNX5800, FAST Cache can be enabled online and with total transparency to the virtualization or application layers. During the test, we configured six 200 GB flash drives for FAST Cache and enabled FAST Cache on the SQL Server OLTP data pool. FAST VP design After completing the baseline test, we expanded the storage pool with two 200 GB flash drives. We set the tiering policy for the data LUNs inside the storage pool to Start High then Auto-Tier, which is the default and recommended setting. During the FAST VP testing, to ensure that the hot data was moved to the highest tier as soon as possible, we manually started the data relocation with the relocation rate set to High, as shown in Figure 10. Figure 10. FAST VP data relocation setting 25

26 FAST Cache design As shown in Figure 11, we configured six 200 GB flash drives and enabled FAST Cache on the SQL Server OLTP data pool for the FAST Cache test. Figure 11. FAST Cache configuration Data protection In this solution, to protect SQL Server OLTP databases, we took advantage of AppSync and VNX Snapshots. VNX Snapshots uses Redirect on Write (ROW) technology. ROW redirects new writes destined for the primary LUN to a new location in the storage pool. Because VNX Snapshots requires pool space, when we designed the pool capacity, we calculated the space required by snapshots based on the data changes of the running OLTP workloads and the number of snapshots we wanted to keep. To control snapshot growth, we enabled VNX Snapshots Auto-Delete, which avoids having the snapshots take usable space away from pool LUNs. EMC VNX Snapshots provides more details about VNX Snapshot Auto-Delete. VMware configuration When deploying SQL Server 2012 in a VMware environment, you should apply some VMware and Microsoft best practices related to CPU, memory, and storage to achieve optimal database performance. Virtual machine configuration We deployed SQL Server virtual machines with the configuration shown in Table 8. 26

27 Table 8. Virtual machine name SQL Server virtual machine configuration vcpu Memory Disk vscsi controller SQL Server Virtual Machine GB 100 GB VMDK for OS, paging file, and SQL Server Master database files 1,500 GB VMDK for 1 TB SQL Server data files 400 GB VMDK for 250 GB SQL Server data files 400 GB VMDK for tempdb data files 0:0 (LSI Logical SAS) 1:0 (Paravirtual) 2:0 (Paravirtual) 3:0 (Paravirtual) 200 GB VMDK for log files 3:1 (Paravirtual) SQL Server Virtual Machine GB 100 GB VMDK for OS, paging file, and SQL Server Master database files 750 GB VMDK for 500 GB SQL Server data files 250 GB VMDK for 50 GB SQL Server data files 400 GB VMDK for tempdb data files 0:0 (LSI Logical SAS) 1:0 (Paravirtual) 2:0 (Paravirtual) 3:0 (Paravirtual) 200 GB VMDK for log files 3:1 (Paravirtual) Note: In this test environment, we enabled Intel Hyper-Threading Technology on both ESXi hosts running SQL Server instances. This enabled the hosts to use the processor resources more efficiently, and enable multiple threads to run on each core. We evenly distributed the SQL Server database files across multiple SCSI controllers. When configuring the SCSI controller type, we set the SCSI controller type for the SQL Server data disks as Paravirtual. VMware Paravirtual SCSI (PVSCSI) adapters are highperformance storage drivers that can improve the throughput and reduce CPU usage. As shown in Figure 12, we provisioned the Virtual Machine Disk (VMDK) files as Thick Provision Lazy Zeroed in vsphere, which corresponds to configuring all the pool LUNs as thin provisioning. When you use Thick Provision Lazy Zeroed, the configured capacity in the vsphere datastore is reserved for future use. However, the setting does not require you to fully allocate capacity from the array, and it does not take additional time to zero the disks, which accelerates the process of creating virtual disks. 27

28 Figure 12. Disk provisioning In this solution, to avoid moving two critical SQL Server virtual machines to the same host, we affined the virtual machines on specified hosts separately by creating the anti-affinity rules shown in Figure 13. Figure 13. Virtual machine affinity rule setting 28

29 Memory settings In this solution, we followed the VMware and Microsoft best practices to configure the virtual machine memory for SQL Server virtual machines to guarantee the best performance. In ESXi environments, when the system is under memory pressure, the hypervisor notifies the balloon driver running inside the guest OS to reclaim memory from any virtual machine including SQL Server virtual machines, which significantly impacts SQL Server performance. To avoid memory balloon, you should fully reserve memory for SQL Server virtual machines as shown in Figure 14. Figure 14. Reserve guest memory In ESXi environments, a guest memory access needs to be translated twice to access the physical memory address on the ESXi host. This translates the guest virtual memory address to the guest physical memory address and translates the guest physical memory address to the host physical memory address. The translation look-aside buffer (TLB) on the CPU has stored a map directly from the guest virtual memory address to the physical memory address; therefore, a TLB hit can improve memory access performance, but a TLB miss results in worse performance. To reduce TLB misses and make TLB cover a larger memory range, you can possibly reduce TLB misses by using large pages. To enable large page allocation, configure from both the host and the guest. From the host, you can enable large page allocation by setting the Mem.AllocGuestLargePage option to 0, as shown in Figure 15. From the guest, you can enable it by adding trace flag 834 to the SQL Server startup parameters. Note: Trace flag 834 applies only to 64-bit versions of SQL Server. You must have the correct Lock pages in memory user to turn on trace flag

30 Figure 15. Large page allocation setting Application design and configuration The following sections provide the design and configuration guidelines for SQL Server 2012 and AppSync server to protect the SQL Server instances. SQL Server 2012 design and configuration Design and requirements The following list shows the Windows and SQL Server 2012 configuration of each virtual machine. Default values were used for all other settings: Use Large Pages for the SQL Server instance by enabling the 834 startup parameters. Use Lock Pages in Memory for the SQL Server service account. Use the 64K format unit for all data and log LUNs. Set Max Server Memory to limit SQL Server available memory. Pre-allocate data files for both SQL OLTP and tempdb databases to avoid autogrow during peak time, and enable instant file initialization for the SQL Server startup service account to accelerate the process of initializing database files. 30

31 Use multiple files for data and tempdb. Place the tempdb data files and log files on separate LUNs from an RAID 10 SAS storage pool. Note: Instant file initialization is available only if the SQL Server (MSSQLSERVER) service account has been granted SE_MANAGE_VOLUME_NAME. Members of the Windows Administrator group have this right and can grant it to other users by adding them to the Perform Volume Maintenance Tasks security policy. SQL Server Best Practices provides more information about best practices for SQL Server configuration. As shown in Table 5 on page 19, the SQL Server 2012 configuration consists of two SQL Server instances. Instance 01 hosts the 1 TB and 250 GB OLTP TPCE-like databases, while instance 02 hosts the 50 GB and 500 GB OLTP TPCE-like databases. We ran a heavy OLTP-like workload with a read/write ratio of approximately 90/10 against the databases with a total user count of 180,000. Note: The read/write ratio is determined by the OLTP workload tool. LUN configuration We configured the VNX5800 storage pool enabled by EMC FAST VP to host SQL Server data LUNs. The LUNs hosted virtual machine operating system files, along with SQL Server data, log, and tempdb files, for both SQL Server OLTP database instances, as shown in Table 9. Table 9. VNX5800 LUN configuration with two-tier storage pool enabled by FAST VP Item Component Storage pool LUN capacity (GB) LUN owner FAST VP policy SQL Server instance 01 tempdb SQL Server tempdb and log pool 500 SP B N/A tempdb log SQL Server tempdb and log pool 300 SP B 1 TB OLTP database SQL Server OLTP data pool 2000 SP A Start High then Auto- Tier 250 GB OLTP database SQL Server OLTP data pool 500 SP A 1 TB OLTP database log SQL Server tempdb and log pool 300 SP B N/A 250 GB OLTP database log SQL Server tempdb and log pool 50 SP B 31

32 Item Component Storage pool LUN capacity (GB) LUN owner FAST VP policy Virtual machine operating system Virtual machines OS pool 100 SP B N/A SQL Server instance 02 tempdb SQL Server tempdb and log pool 500 SP A N/A tempdb log SQL Server tempdb and log pool 300 SP A 500 GB OLTP database SQL Server OLTP data pool 1000 SP B Start High then Auto- Tier 50 GB OLTP database SQL Server OLTP data pool 250 SP B 500 GB OLTP database log SQL Server tempdb and log pool 200 SP A N/A 50 GB OLTP database log SQL Server tempdb and log pool 50 SP A Virtual machine operating system Virtual machines OS pool 100 SP B N/A AppSync design and configuration AppSync 1.6 supports protecting VMware datastores. In this solution, we configured all database and log LUNs as VMFS datastores to take advantage of Microsoft Volume Shadow Service (VSS) framework functionality for application recovery. In our test environment, we used AppSync 1.6 to protect the 500 GB SQL Server database with running OLTP workload. Follow these steps to configure the AppSync server to create application-consistent copies of the SQL Server OLTP database to protect database corruption: 32

33 Adding storage We added the VNX5800 as a managed storage array in AppSync. We entered the IP addresses of SP A and SP B, as shown in Figure 16, and provided the user credentials to log in to the storage system. Figure 16. Add storage to AppSync server Adding VMware vcenter Server We added the vcenter Server that manages the ESXi hosts to the AppSync server as shown in Figure 17. This allows us to protect, mount, and restore SQL Server standalone and clustered databases residing on VMware virtual disks. For successful mapping to the virtual disks, the vcenter Server must be added to the AppSync server and discovery must be performed. 33

34 Figure 17. Add VMware vcenter Server to AppSync server 34

35 Adding host We added the SQL Server virtual machine to the AppSync server, as shown in Figure 18. The SQL Server application we want to protect is running on the host. AppSync server pushes the plug-in software from the AppSync server to the host when you add the host as a resource. You can also install the plug-in manually on the host, and then add the host to the AppSync server. Figure 18. Add host to AppSync server Discovering SQL Server instances and databases We discovered the SQL Server instances and the OLTP databases running on them, as shown in Figure

36 Figure 19. Discover SQL Server databases To keep AppSync up to date, you should discover SQL Server instances when you create or delete instances. This operation requires that you have the Data Administrator role in AppSync and know the credentials for the SQL Server instances. After connecting to the SQL Server databases, AppSync shows the SQL Server User Databases folder, shown in Figure 20, which contains all the user databases that have been discovered and stored in the AppSync database. Figure 20. User database in SQL Server instance Creating service plan We created a service plan to protect the SQL Server OLTP database by creating snapshots, and executed the plan on schedule. 36

37 After establishing the connection with SQL server, you can start to configure the service plan. AppSync provides three default service plans: Gold Creates Microsoft SQL Server full local and remote backup copies Silver Creates Microsoft SQL Server full remote backup copies Bronze Creates Microsoft SQL Server full local backup copies You can also create a new service plan by using an existing plan as a template. The new service plan contains the same schedule and other settings as the template, but there are no objects subscribed to the new service plan. You can override the new service plan s Plan Startup and Create Copy settings to specify separate configurations for individual objects that are subscribed to the plan. Plan Startup In this solution, we configured the recovery point objective (RPO) as one hour and ran the service plan on schedule to create snapshots. In the Plan Startup phase of the service plan, you select a recurrence type based on when the service plan is triggered. This recurrence type is applicable for all application objects that are subscribed to a service plan. However, you can override the settings and specify separate settings for selected objects. A service plan's Startup Type (scheduled or on demand) determines whether the plan is run manually or configured to run on a schedule. Options for scheduling when a service plan starts are: Run every day at certain times Run at a certain time on selected days of the week Run at a certain time on selected days of the month Specify an RPO AppSync support an RPO of 30 minutes or 1, 2, 3, 4, 6, 8, 12, or 24 hours. The default RPO in AppSync is 24 hours. In our testing environment, we set the Startup Type as Scheduled and RPO as 1 hour. 37

38 Figure 21 shows the Service Plans tab. Figure 21. Service Plans tab Create Copy We created a full backup of the SQL Server OLTP database, chose VNX Snapshots as the replication technology, and kept the maximum number of VNX Snapshots copies at four, as shown in Figure 22. Figure 22. Create Copy configuration 38