CONSOLIDATING MICROSOFT SQL SERVER OLTP WORKLOADS ON THE EMC XtremIO ALL FLASH ARRAY

Transcription

1 Reference Architecture CONSOLIDATING MICROSOFT SQL SERVER OLTP WORKLOADS ON THE EMC XtremIO ALL FLASH ARRAY An XtremIO Reference Architecture Abstract This Reference architecture examines the storage efficiencies and the performance profile of Microsoft SQL Server 2014 OLTP workloads when using the always-on Inline Data Reduction and copy services of EMC's XtremIO All Flash Storage Array. March 2015

2 Copyright 2015 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. The information in this publication is provided "as is". EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. All other trademarks used herein are the property of their respective owners. Part Number H

3 Table of Contents Executive Summary... 4 Audience... 5 Introduction... 6 Background on OLTP Workloads... 6 Reference Architecture Setting... 7 Hardware... 7 Software... 7 Database Configuration... 8 SQL Server Configuration... 8 Configuring Indirect Checkpoints on MS SQL Server... 9 Testing Methodology OLTP Benchmarking Tool Storage Efficiency in MS SQL Server Database Environments Database Duplication Illustrative Example of Deduplication Benefits A Note on Compression Provisioning Microsoft SQL Database Copies from XtremIO Snapshots Advantages of XtremIO Snapshots Performance Profile of a Single X-Brick Array Running the OLTP Tool on the Primary Database Running the OLTP Tool on Clones of the Primary DB Running the OLTP Tool on a Clone Created via XtremIO's Snapshot Running the OLTP Tool on the Primary Database and a Clone (Created via XtremIO Native Snapshots) Conclusion References and Additional Information

4 Executive Summary This reference architecture examines the Microsoft SQL Server OLTP (Online Transaction Processing) workload benefits when using the XtremIO All Flash Storage Array. The storage efficiency of the XtremIO array and the performance results from testing with an industry standard modern OLTP benchmark are also discussed in this reference architecture. Storage efficiency and OLTP performance are two of the most important factors to be considered when evaluating SQL Server workloads. Databases are widely adopted in the enterprise, as they have become the foundation of all business systems. However, the proliferation of databases has led to some inefficient practices that further contribute to the database sprawl. For example, it is quite common to create multiple copies of a database to be used in production for other applications (such as analytics and reporting). In addition, they can be used to test and develop new versions of applications in order to use the same data. This increases storage sprawl and the associated capital and management costs. Far worse, the agility of the operational workflow is unnecessarily limited. These separate silos and the overheads incurred by brute-force copies usually mean that dev/test and analytics teams neither receive the number of copies they require, nor as frequently as they want them. Finally, many secondary copies are stored on tier-2 or tier-3 storage environments, with sub-par performance that hinders their objectives. The EMC XtremIO All Flash Storage Array, with its powerful always-on Inline Data Reduction and space-efficient in-memory copy services, solves this problem by consolidating databases without any capacity or performance SLA penalties. In addition, it provides the service levels that can be expected from an all-flash platform. XtremIO's Storage Array has the benefit of increasing CPU utilization on the database server platforms, reducing inefficiencies and allowing for fewer servers. Reducing capital expenditure and operating expenses are among the major factors driving enterprises to consolidate their database servers onto EMC XtremIO Storage Arrays. As the XtremIO infrastructure can now be centrally managed as a consolidated infrastructure for all instances, database storage sprawl can be eliminated. Most importantly, database and application administrators gain dramatic agility benefits, with instant on-demand, full-performance copies for real-time analytics, on-demand reporting, and accelerated dev/test capability. This reference architecture demonstrates the underlying performance consistency and the ability to meet all SLAs in mixed production and non-production consolidated environments. 4

5 Audience This reference architecture is intended for storage and database solution architects currently working with (or considering) Microsoft SQL Server with the XtremIO All Flash Storage Array. Enterprise Microsoft database environments looking to improve their OLTP implementations should benefit by reviewing the storage efficiency features and the performance test results. This document will benefit anyone evaluating or pursuing highly efficient Microsoft database solutions that yield maximum IOPS and sub-millisecond latency. 5

6 Introduction EMC XtremIO is an all flash storage array that has been designed from the ground-up to unlock flash's full performance potential and deliver array-based capabilities that leverage the unique characteristics of SSDs, based on flash media. The EMC XtremIO All Flash Storage Array automatically reduces data on the fly as it enters the system. It removes duplicate patterns and then compresses the remaining unique pattern before writing the data block to SSD. This reduces the amount of data written to flash, improving longevity of the media and driving down cost. OLTP applications dominate the enterprise application landscape and are in the critical path of all revenue generating activities. The I/O profiles of such workloads can introduce a lot of stress on the underlying infrastructure (both compute and storage) as it tries to keep up with the IOPS demand and maintain low latency. The purpose of this reference architecture is two-fold. First, it presents results demonstrating how Microsoft SQL Server OLTP workload profiles enjoy substantial storage capacity savings because of the always-on Inline Data Reduction features of the EMC XtremIO Storage Array. These storage efficiencies do not come at the cost of sub-optimal performance. Secondly, this paper documents test results demonstrating substantial performance of OLTP workloads running on multiple Microsoft SQL Server databases hosted on Intel servers and a single EMC XtremIO Storage Array. Background on OLTP Workloads OLTP systems are among the most common data processing systems in today's enterprises. Classical examples of OLTP systems are order entry, retail sales, and financial transaction systems. OLTP workloads are primarily characterized by: Short response time Small transactions With MS SQL Servers, typical I/O patterns for OLTP workloads include transaction queries, transaction log writes and checkpoint activity (to flush memory to disk periodically). Since transactions are synchronous in nature, they have a direct impact on the OLTP workload performing writes to the database. While each transaction is small, it updates several database tables. OLTP workloads are intrinsically parallel and DB systems employ multiple servers to process client transactions. OLTP database systems typically service hundreds or thousands of concurrent users. The OLTP database transactions, performed by these thousands of concurrent users, are translated into tens of thousands of I/O requests to the backend storage subsystem, depending on the nature of these OLTP transactions. The database host CPUs are only efficiently utilized if the storage subsystem is capable of servicing I/O requests with very low latency. 6

7 Reference Architecture Setting Figure 1. Reference Architecture Diagram Hardware The testing for this reference architecture was performed on two industry standard Intel servers (with 2-10 core Intel E GHz CPUs and 320 GB of RAM). Each Intel server was equipped with a single dual ported Emulex LPe Gen5 HBAs which attached via a Brocade Gen5 16GFC SAN to a single X-Brick array. Software The significant configuration settings are detailed below: Microsoft SQL Server (X64) Windows Server 2012 R2 7

8 Database Configuration For this test, two databases were used on each Intel server. The databases' configurations are detailed in Table 1. Table 1. Database Configurations Used on Intel Servers Parameter MS SQL database Data files MS SQL database Log files MS SQL database Temp DB Database size Number of users for the OLTP workload Value 800GB 100GB up to 1 TB 125GB (TempDB + Log) 1.25TB 110 users SQL Server Configuration For all tests documented in this reference architecture, the following configurations were employed on the physical Windows server machine with MS SQL Server: The basic disk type was used when formatting the XtremIO LUNs for use with the Windows server. The NTFS file system allocation unit was configured to be 64K for the SQL database and Transaction Log partitions. From Automatic checkpoints, Target Recovery Time was modified to 15 seconds for all DBs used in performance benchmarks. This configuration change enables indirect checkpoints and establishes 15 seconds as an upper-bound recovery time for the pertinent DBs. The indirect checkpoint configuration is discussed in the next section. All other SQL Server configuration settings remained with their default values. For instance, the SQL Server recovery model of TempDB was set to SIMPLE. 8

9 Configuring Indirect Checkpoints on MS SQL Server While both the traditional MS SQL checkpoint configuration and indirect checkpoint configuration were evaluated during the validation testing of this reference architecture, the performance numbers that are presented in this document are only with the indirect checkpoints configured. Indirect checkpoints are in effect when the Target Recovery Time configuration parameter is set to a value greater than zero. This setting allows the SQL Server to calculate and internally set a threshold (or a "target") for the number of dirty buffers to keep in the buffer cache after which the dirty buffers are flushed to disk. This ensures that at any given point-in-time there is not more than "target" dirty buffers in the Buffer Pool. Traditionally, the MS SQL Server checkpoint process scans the buffer cache periodically and writes any dirty pages for a particular database to disk. In our case, it was written to the SSDs on the EMC XtremIO All Flash Storage Array. It was observed during testing that the flushing of dirty buffers to disk results in I/O spikes at the time of checkpoint. This is illustrated in Figure 2 and Figure 3, where the dark shaded spikes represent the writes. Figure 2. IOPS Observed when Running the OLTP Tool with Traditional Checkpoints While testing with the OLTP tool, it was observed that when indirect checkpoints were configured, the I/O spikes occurring at checkpoints were smoothened out. This is illustrated in Figure 3. Figure 3. IOPS Observed when Running the OLTP Tool with Indirect Checkpoints A detailed discussion about the pros and cons of using traditional checkpoints versus indirect checkpoints is beyond the scope of this whitepaper. While indirect checkpoints yielded better results during test runs with the OLTP tool, its usage should be carefully considered before being adopted in production environments. 9

10 Testing Methodology This reference architecture aims to demonstrate two important qualities of the EMC XtremIO All Flash Storage Array: 1. The space efficiency realized when multiple copies are created from a single source database. This is a common use case in MS SQL Server environments. 2. The consistent performance that can be realized when OLTP workloads are run on a single MS SQL database or its copy or a combination thereof. The testing methodology comprised of a series of tests on the primary MS SQL 2014 database or a copy of the primary database. From a performance perspective, the primary objective of this reference architecture was to characterize the performance of OLTP workloads when running on the EMC XtremIO All Flash Storage Array. A secondary objective was to verify that the performance of an SQL Server database remained constant regardless of the method used to deploy it. The testing used an industry standard benchmark OLTP tool to generate I/O through the database. A performance baseline was established by running the OLTP tool against the primary or MS SQL database. Since subsequent tests comprised of running the OLTP tool on copies of this MS SQL database, the MS SQL database used has been labeled the primary DB. Performance was also characterized on copies of the primary DB. These copies were created by three methods: 1. Using MS SQL 2014 to first backup the primary database and subsequently restore a copy of the primary DB. 2. Detaching the primary MS SQL 2014 database on the source server, copying the database files over to the destination server and then attaching the database at the destination servers. 3. Using XtremIO snapshots to create a copy of the original LUN. Once the baseline performance characteristics were established by using the primary datasets, subsequent tests were run on copies of the primary databases created via one of the three methods described above. These tests help simulate the consolidation of MS SQL workloads on the XtremIO Storage Array. To summarize, there were four different tests conducted to characterize the performance of MS SQL Server OLTP workloads on XtremIO: 1. Running the OLTP tool against the primary copy of the MS SQL 2014 database. 2. Running the OLTP tool against a copy of the primary DB. The copy of the primary database is created by first detaching the primary database, copying the database files and then reattaching the database. The database is renamed prior to reattaching. 10

11 3. Running the OLTP tool against a copy of the primary DB created from snapshot(s) of the LUN(s) on which the primary DB resides. 4. Running the OLTP tool against the primary DB as well as its copy created by the "detach-attach" method and a copy of the primary DB created from snapshot(s) of the LUN(s) on which the primary DB resides. OLTP Benchmarking Tool An industry standard modern OLTP benchmarking testing tool that uses SQL in a Microsoft SQL Server 2014 database to model a brokerage house was used for performance characterization. The database tables keep information about the customers, brokers, and market. The transactions simulate a workload where either the customers initiate transactions or the market sends ticker feeds or trade results to the brokerage house. The brokerage house responds to the customers, checks the orders to decide whether to submit them or not, submits the related brokerage requests (brokerage initiated transactions), and analyzes or updates the database. The OLTP database has many tables, some of which are of a fixed size while others are either scaling tables or growing tables. The OLTP tool executes a specific number of transactions against this database. The majority of the transactions are read-only while the remaining transactions are update-heavy. The test criteria used for this reference architecture were: All database access latencies (read, write, transaction log) remain below one millisecond. The CPU utilization on the SQL Server remain below 70%. 11

12 Storage Efficiency in MS SQL Server Database Environments An MS SQL Server database is made up of one or more data files and one or more log files. The objects that make up the database such as the data, tables, indexes and stored procedures are all stored in the data files. Every database has one primary data file and multiple secondary data files. The transactions belonging to the database are first logged to the transaction log before being written to the data files. All database files are grouped into a logical unit known as a filegroup. Filegroups enable the separation between logical object placement and physical database files. When database objects such as tables are created, the database administrator specifies in what filegroup they should be placed without worrying about the underlying data files configuration. When these database objects are added to a filegroup, the MS SQL database initializes every data block with a unique header and tail structure that is universally unique to the database. To that end there are no duplicate blocks in a single MS SQL database. Note that deduplication benefits not only occur from the data that comprises a database. Typical database environments include production OLTP servers, multiple reporting servers, staging servers, servers for test and development, etc. In such environments, there is a need to create multiple copies of the same database. Microsoft offers guidelines and procedures on how to create these copies. Refer to references 34 and 4 in the References and Additional Information section on page 28. These copies of the same database enjoy maximum deduplication. As such, great storage efficiencies can be realized without the need to sacrifice performance when the underlying storage array is XtremIO. Database Duplication The main motivation behind cloning MS SQL databases is the need to create a separate database that contains all of the data contained in the source database. These duplicate databases can then be used for a variety of purposes within the enterprise. It is a common practice in enterprise database environments to create multiple copies of the MS SQL database for use in production. There are several reasons for duplicating production databases. Some of the important use cases are: Reporting environments Many reporting tools require read (and sometime write) access to the primary database. QA environments Can be used to test the effect of applications on database performance. Effective integration and performance testing requires recent copies of production data. 12

13 Development environments Developers need access to the production copy of the data for effective unit testing and to develop new features and functionality into applications. Test backup and recovery procedures To be used, for example, when the production database is duplicated from one host to another. The duplicate copy of the database is then used to practice restoring and recovering this database while the production database operates as usual. Environment management The duplicate database can be used to test an upgrade to a new release of the MS SQL 2014 database software. New versions of build scripts can be tested against the production data. Data recovery Data, such as a table that was inadvertently dropped from the production database, can be exported and then imported back into the production database. Training environments Many of applications request a training version, which can be used for integration testing. Broadly speaking, there are three different mechanisms for duplicating (or cloning) the production database. 1. Using native MS SQL Server backup and restore tools to clone the primary database: Restoring the database from backup automatically creates all of the database files. 2. Detaching the data and transaction logs of the primary database, copying these database files and finally reattaching these copies to the same or another instance of the SQL Server: This method of creating a copy of the database is typically employed when you want to change the primary database to a different instance of SQL Server on the same computer or to move the database. 3. Using the volume snapshot feature of the XtremIO Storage Array to create a pointin-time copy of the volume(lun) or group of volumes(luns) on which the production database is stored. 13

14 Note: Native SQL Server backup techniques create SQL database backups using tools and utilities native to Microsoft SQL Server. The native database backup tool was used to perform a full database backup of the primary database. The native tools that are used to perform the full backup are able to skip some datafile blocks that do not currently contain data, reducing the size of the backup file(s). Consequently, the backup data pattern on disk will differ from the original database pattern and does not deduplicate. Finally, while it is possible to compress the resulting data files using the native backup tools, this is no longer necessary if the backup files are stored on the XtremIO array. The XtremIO array compresses the data before storing it on the SSD drives. All options have their own advantages and customers have a choice in using the approach that is most appropriate for their infrastructure. The following section (Illustrative Example of Deduplication Benefits) demonstrates the savings that can be expected when using the MS SQL native backup copy approach to deploying clones of the SQL Server databases. The benefits of using the XtremIO snapshot-based approach are discussed in Advantages of XtremIO Snapshots on page

15 Illustrative Example of Deduplication Benefits The following figures demonstrate the capacity savings that arise from having multiple copies of the same database on an XtremIO array. In the example below, two databases are initially created on the XtremIO array. These are the "primary" databases. The workflow then illustrates the deduplication ratio that is achieved after restoring the primary databases using the native MS SQL backup and restore utilities. The figure below shows the logical and physical capacity consumed when one 1.25TB OLTP database has been provisioned on a single X-Brick cluster. This constitutes the primary copy of the "production" databases. Note the deduplication ratio of 1:1. 15

16 In the next method the MS SQL 2014 native restore utilities were used to restore a copy of the primary database from backup. The restored copy existed on a different server. Because the original database and the copy both reside on the XtremIO array, the deduplication ratio now increases to 1.9:1. 16

17 Finally, a third method of creating a copy of the primary database is employed. The primary database is detached and Windows utilities are used to copy the data and transaction log files. The primary database and the copy are then attached and brought online. Since there are now three copies of the primary database, the original, the backup copy and finally the clone created via "detach-copy-attach", the deduplication ratio is now 2.8:1. It would not be uncommon to observe a 3:1 deduplication ratio in actual customer environments. A Note on Compression XtremIO automatically compresses data after all duplicate data has been removed. This ensures that the compression operation is only performed on unique data blocks. Just as in deduplication, data compression is performed in real time and not as a post processing operation. The nature of the data set determines the overall compressibility rate. The compression ratio observed with the OLTP database used in the tests for this reference architecture is 1.5:1. XtremIO's data deduplication and data compression complement each other. Data deduplication reduces physical data, by eliminating redundant data blocks. Data compression further reduces the data footprint, by eliminating data redundancy within the binary level of each data block. 17

18 Provisioning Microsoft SQL Database Copies from XtremIO Snapshots Deploying MS SQL 2014 databases using XtremIO point-in-time snapshots is extremely fast and efficient. All meta-data operations happen in memory and consume no capacity. The figure below depicts the XtremIO dashboard after an additional clone of the primary database is brought online by mounting a point-in-time copy of the database onto a different server. The snapshot of the primary database is actually taken while the database is up and performing transactions. There is no material change in the deduplication ratio since the snapshot volumes are all based on pointers to the original blocks of data. Snapshot volumes are not a type of duplicated blocks as would be performed by a copy tool such as an SQL Server Restore operation. Nonetheless, the space savings are real since the snapshot represents the capacity that does not have to be provisioned. This is illustrated in the dashboard by noting that the provisioned volume capacity increased to 21TB. 18

19 Advantages of XtremIO Snapshots There are many reasons for using the XtremIO array-based snapshot features for creating a copy of the production database. Typically, cloning databases using native MS SQL Server backup tools can be time consuming. On the other hand, a point-in-time copy of the database is created much faster, typically within a few seconds, by using snapshots rather than the complete physical copy. The capacity required to store the copy or copies of the production database can be expensive. Maximizing the return on hardware is an important business concern today. XtremIO's unique architecture ensures that creating a point-in-time copy takes up no space on the array. Different groups have different requirements. In most enterprise environments, development, QA and reporting teams may have different needs requiring different environments. If multiple projects run concurrently there will be a need for even more environments. 19

20 Performance Profile of a Single X-Brick Array The results from running the suite of tests are presented below. The I/O profiles of typical OLTP systems are dynamic in nature and are heavily dominated by reads. Conventionally a 70:30 read/write ratio is assumed for OLTP workloads. However, in practice, the reads may be anywhere from 90% to 70% of the I/O mix. The industry standard modern OLTP workload is typically very memory and CPU intensive. In general, the OLTP transactions for this workload produce read/write ratios that vary between 80:20 and 85:15. Running the OLTP Tool on the Primary Database A baseline test is run with the primary copy of the database. The baseline establishes the optimal IOPS that can be achieved when running the industry standard modern OLTP workload while maintaining an average latency of below one. Two databases on two different SQL Servers were used to establish the baseline IOPS number The performance results during the duration of the industry standard modern OLTP benchmark test are shown in Figure 4, Figure 5 and Figure 6. Figure 4.IOPS Observed when Running the OLTP Tool on the Primary Database Figure 5. Observed Latencies (Read and Write) 20

21 Figure 6. Throughput Observed when Running the OLTP tool on the Primary Database OLTP Number of Users % Update OLTP Profile IOPS Average Latency Average Array CPU Utilization Read Ratio Average I/O Block Size KB These results demonstrate that a single X-Brick operates within a range of 115K to 118K IOPS at sub-millisecond latencies. While the write latency was observed to be between 1.3ms and 1.5ms, the read latency was extremely low at around 0.75ms. Since this specific OLTP workload is a read heavy workload, the average latency is below one millisecond. Note: A single X-Brick is capable of supporting between 115K IOPS and 118K IOPS, while maintaining consistent sub-millisecond latency. It is important to note that considerably higher IOPS are possible, but that would lead to higher latencies. While higher latencies could be acceptable for certain applications, XtremIO is a high performance all flash array and this reference architecture strives to present numbers at sub-millisecond latencies. It should also be noted that the XtremIO storage system is designed to scale out in order to meet future performance and capacity needs. The XtremIO architecture allows performance and capacity to be increased by simply adding building blocks (X- Bricks). 21

22 Running the OLTP Tool on Clones of the Primary DB Figure 7, Figure 8 and Figure 9 illustrate the performance observed when running the industry standard OLTP benchmarking tool on clones of the primary database. These clones or copies of the primary database are created by the "detach-attach" method which is explained in detail in the Microsoft Technet document entitled "Database Detach and Attach". Refer to reference 5 in the References and Additional Information section on page 28. Figure 7. IOPS Observed when Running the OLTP Tool on Clones Figure 8. Throughput Observed when Running the OLTP Tool on Clones Figure 9. Observed Latencies (Read and Write) OLTP Number of Users % Update OLTP Profile IOPS Average Latency Average Array CPU Utilization Read Ratio Average I/O Block Size KB 22

23 The performance of the cloned databases is consistent with that observed when testing on just the primary DB. This is an expected result. However, it is displayed here to prove the concept that the copied database is, in essence, an instantaneous replica of the primary database with all the data contained and with immediate availability at the necessary service levels. It also serves to emphasize the point prevalent in this reference architecture that XtremIO Storage Array's deduplication capability ensures that no additional capacity is consumed with the cloned copy of the DB. Running the OLTP Tool on a Clone Created via XtremIO's Snapshot In the set of results below, XtremIO's snapshot technology was used to create clones of the primary databases. The OLTP tool was used to run the industry standard OLTP benchmark workload on these clones created via snapshots. The results are documented in Figure 10, Figure 11 and Figure 12. Figure 10. IOPS Observed when Running the OLTP Tool on Snapshot Based Clones Figure 11. Throughput Observed when Running the OLTP Tool on Snapshot Based Clones Figure 12. Observed Latencies (Read and Write) 23

24 OLTP Number of Users % Update OLTP Profile IOPS Average Latency Average Array CPU Utilization Read Ratio Average I/O Block Size KB Again, the performance of the database created from a snapshot is consistent with that observed when testing on just the primary database. In addition, the natural progression of this test sequence shows that this is the third copy of the primary database. XtremIO's space efficient snapshot technology ensures that no additional physical capacity is consumed on the storage array. Running the OLTP Tool on the Primary Database and a Clone (Created via XtremIO Native Snapshots) In the set of results below, the OLTP tool was used to run the industry standard OLTP benchmark workload on both the primary database, as well as a clone of the primary database that was created via XtremIO's snapshot technology. The results are documented in Figure 13, Figure 14 and Figure 15. Figure 13. IOPS Observed when Running the OLTP Tool on Consolidated Databases Figure 14 Throughput Observed when Running the OLTP Tool on Consolidated Databases 24

25 Figure 15. Observed Latencies (Read and Write) OLTP Number of Users % Update OLTP Profile IOPS Average Latency Average Array CPU Utilization Read Ratio Average I/O Block Size KB The table above shows the performance results seen during this test. As expected, the performance is consistent with that observed with just the primary database. The figures and tables in the preceding sections show that for a typical OLTP workload that resembles an industry standard modern OLTP benchmark (with approximately 15% writes), a single X-Brick is capable of supporting between 115K IOPS and 118K IOPS, while maintaining consistent sub-millisecond latency. Although the storage CPU utilization is well under 70% at the IOPS levels shown, the test did not attempt to continue increasing the load due to the testing criteria of keeping latency at submillisecond level. 25

26 Conclusion The EMC XtremIO Storage Array is a high performing yet cost effective platform for Microsoft SQL Server 2014 solutions, which is well suited to meet the most demanding OLTP workloads. It uniquely demonstrates the consistent IOPS and low latency performance for production, non-production and consolidated combinations of the database copies. The performance remains consistent regardless of whether the copies are made via SQL Server native tools to restore backup copies or via XtremIO's space-efficient snapshots. Therefore, it is easy to have multiple copies of a database being serviced by several database servers and application servers and maintain all service levels demanded from the storage system when operating within the scale-out performance window of the XtremIO Storage Array. There is no capacity penalty for such copies, and therefore database administrators can create as many copies as desired and as frequently as needed. Figure 16 summarizes the performance profile for XtremIO clusters of different sizes when executing the industry standard OLTP benchmark workload. A single X-Brick cluster can deliver 116K IOPS. The performance will then scale such that a dual X- Brick cluster delivers exactly twice as much or 232K IOPS. A four X-brick cluster delivers 464K IOPS and a six X-brick cluster delivers 696K IOPS (four times and six times the IOPS of a single X-Brick cluster, respectively). These IOPS can be expected to be delivered at sub-millisecond latencies Expected Maximum IOPS for a Industry Standard OLTP Benchmark Workload (MS SQL Server 2014) Single X- Brick Array Dual X- Brick Array Quad X- Brick Array Six X- Brick Array Maximum IOPS Figure 16 Expected Maximum IOPS on EMC XtremIO Arrays at Sub-Millisecond Latencies 26

27 This unique combination of scale-out consistent performance, aligned with XtremIO's data reduction and copy services, finally enables database consolidation across production and non-production instances on centralized shared storage. This is achieved without risking performance service levels, while dramatically improving workflow agility and lowering infrastructure and licensing costs. The XtremIO All Flash Storage Array is well suited for running OLTP workloads. Furthermore, consolidating copies of production OLTP databases offers the benefits of an all-flash array to different use cases, while lowering the total cost of ownership. XtremIO's All Flash Storage Array has the capacity to meet the demanding and disparate needs of these varied database workloads encountered in the typical enterprise environment. 27

28 References and Additional Information This section contains a list of support documents. 1. Overview of TPC Benchmark E: The next generation of OLTP Benchmarks (IBM white paper) 2. Online Transaction Processing (OLTP) a Technical Reference Guide for Designing Mission Critical OLTP Solutions (Microsoft Technet publication) 3. Copy Databases (Microsoft TechNet) 4. Copy Databases with Backup and Restore (Microsoft TechNet) 5. Database Detach and Attach (Microsoft TechNet) 6. SQL Server Database Checkpoints (Microsoft TechNet documentation) 7. Introduction to the EMC XtremIO All Flash Storage Array (EMC white paper) 8. Introduction to XtremIO Snapshots (EMC white paper) For Case Studies, Solution Guides, Demos, and other Reference architectures, go to 28